T06 · System Persistence
- Location
SYSTEMD_SETUP.md:45- Finding
Persistent Autonomous Trading Service and Scheduled Restart
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is an openly disclosed crypto trading bot, but it can autonomously trade real funds and combines live credentials, persistence, external code execution, and weak safety boundaries.
Review this carefully before installing. Use paper trading or testnet first, pin exact commits and package versions, run in an isolated virtual environment, avoid sourcing secrets into a general shell, disable withdrawals, IP-allowlist Binance keys, and do not enable systemd or cron persistence until you have audited the executor and oracle code and accepted autonomous live trading risk.
SYSTEMD_SETUP.md:45Persistent Autonomous Trading Service and Scheduled Restart
CONFIGURATION.md:225Unpinned Remote Dependencies Are Downloaded and Executed with Credential-Bearing Environment
executor.py:961OCO Failure Fallback Does Not Create a Stop-Loss Order
executor.py:1021Trailing Stops Are Updated Only in Local State and Not on Binance
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
""
import sys
import json
import os
import time
import subprocess
import threading
from datetime import datetime, timedelta
from pathlib import Path
import urllib.request
import urllib.error
import hashlib
import hmac
import concurrent.futures
from collections import deque
# ==========================================
# CONFIGURATION
# ==========================================
BINANCE_API_KEY = os.getenv("BINANCE_API_KEY")
BINANCE_API_SECRET = os.getenv("BINANCE_API_SECRET")
TELEGRAM_BOT_TOKEN = os.getenv("TELEGRAM_BOT_TOKEN")
TELEGRAM_CHAT_ID = os.getenv("TELEGRAM_CHAT_ID")
WORKSPACE = Path("/workspace")
ORACLE_SCRIPT = Path("/workspace/skills/crypto-sniper-oracle/crypto_oracle.py")
PROJECTS_FILE = WORKSPACE / "trading_projects.json"
PORTFOLIO_FILE = WORKSPACE / "portfolio_state.json"
TRADES_LOG = WORKSPACE / "trades_history.jsonl"
POSITIONS_FILE = WORKSPACE / "open_positions.json"
PERFORMANCE_FILE = WORKSPACE / "performance_metrics.json"
REPORTS_DIR = WORKSPACE / "reports" / "dail
The guide instructs storing live Binance and Telegram credentials in a plaintext environment file on disk. Even with restrictive permissions, plaintext secret storage increases the blast radius of host compromise, backups, misconfiguration, and accidental disclosure, especially for a bot that can trade real funds.
# Create secure credentials file
sudo mkdir -p /etc/crypto-executor
sudo nano /etc/crypto-executor/credentials.env
# Content:
BINANCE_API_KEY=your_binance_api_key
The documentation tells users or agents to source a file containing exchange and messaging secrets into the current shell environment. That exposes credentials broadly to subprocesses, shell inspection, crash dumps, and any subsequently executed external code, including the separately installed oracle dependency.
To use:
# Load before running bot
source /etc/crypto-executor/credentials.env
# Or use with systemd (see SYSTEMD_SETUP.md)
EnvironmentFile=/etc/crypto-executor/credentials.env
Referencing the same plaintext credential file from systemd continues the design of storing high-value API secrets in a locally readable file. While common operationally, it remains sensitive because compromise of the host or service configuration can reveal live trading credentials.
source /etc/crypto-executor/credentials.env
EnvironmentFile=/etc/crypto-executor/credentials.env
**Why this is better:**
This is another explicit instruction to source live API credentials into the shell before launching the bot. In context, that is especially risky because the same guide later encourages cloning and executing additional code, increasing the chance that secrets leak to child processes or malicious dependencies.
# Load credentials into current session
# Why: executor.py reads these via os.getenv() at startup.
# Without them, bot exits immediately with [ERROR] Missing Binance credentials
source /etc/crypto-executor/credentials.env
# Verify credentials loaded
echo "API Key set: ${BINANCE_API_KEY:0:8}..." # Shows first 8 chars only (security)
This example workflow normalizes an agent loading real exchange credentials and immediately executing the trading bot, reinforcing an unsafe autonomous path with direct access to funds. Combined with persistence and external dependency installation, it materially raises the risk of unauthorized trades or credential abuse if any part of the chain is compromised.
Runs: ls /workspace/skills/crypto-executor/executor.py
↓
✅ File exists → skips installation entirely
Runs: source /etc/crypto-executor/credentials.env
Runs: python3 /workspace/skills/crypto-executor/executor.py
↓
Bot starts in <5 seconds, loads learned_config.json automatically
The instructions explicitly source a credentials file into the shell environment before executing the trading bot, exposing high-value Binance API secrets to the process environment. In combination with shell, file, and network capabilities, this creates a strong path for credential misuse, accidental leakage, or unauthorized live trading if the skill or its dependencies are compromised.
ls /workspace/skills/crypto-executor/executor.py
# ✅ Already installed → just launch:
source /etc/crypto-executor/credentials.env
python3 /workspace/skills/crypto-executor/executor.py
# ❌ Not installed → full install (run once):
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
WorkingDirectory=/workspace/skills/crypto-executor
# Credentials — loaded from secure file (see Security section below)
# Create /etc/crypto-executor/credentials.env first (chmod 600, root-owned)
EnvironmentFile=/etc/crypto-executor/credentials.env
# Execution
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
WorkingDirectory=/workspace/skills/crypto-executor
# Credentials — loaded from secure file (see Security section below)
# Create /etc/crypto-executor/credentials.env first (chmod 600, root-owned)
EnvironmentFile=/etc/crypto-executor/credentials.env
# Execution
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
WorkingDirectory=/workspace/skills/crypto-executor
# Credentials — loaded from secure file (see Security section below)
# Create /etc/crypto-executor/credentials.env first (chmod 600, root-owned)
EnvironmentFile=/etc/crypto-executor/credentials.env
# Execution
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
WorkingDirectory=/workspace/skills/crypto-executor
# Credentials — loaded from secure file (see Security section below)
# Create /etc/crypto-executor/credentials.env first (chmod 600, root-owned)
EnvironmentFile=/etc/crypto-executor/credentials.env
# Execution
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
WorkingDirectory=/workspace/skills/crypto-executor
# Credentials — loaded from secure file (see Security section below)
# Create /etc/crypto-executor/credentials.env first (chmod 600, root-owned)
EnvironmentFile=/etc/crypto-executor/credentials.env
# Execution
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
WorkingDirectory=/workspace/skills/crypto-executor
# Credentials — loaded from secure file (see Security section below)
# Create /etc/crypto-executor/credentials.env first (chmod 600, root-owned)
EnvironmentFile=/etc/crypto-executor/credentials.env
# Execution
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
WorkingDirectory=/workspace/skills/crypto-executor
# Credentials — loaded from secure file (see Security section below)
# Create /etc/crypto-executor/credentials.env first (chmod 600, root-owned)
EnvironmentFile=/etc/crypto-executor/credentials.env
# Execution
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
WorkingDirectory=/workspace/skills/crypto-executor
# Credentials — loaded from secure file (see Security section below)
# Create /etc/crypto-executor/credentials.env first (chmod 600, root-owned)
EnvironmentFile=/etc/crypto-executor/credentials.env
# Execution
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
WorkingDirectory=/workspace/skills/crypto-executor
# Credentials — loaded from secure file (see Security section below)
# Create /etc/crypto-executor/credentials.env first (chmod 600, root-owned)
EnvironmentFile=/etc/crypto-executor/credentials.env
# Execution
The statement that the root-owned credentials file can be 'shared with manual runs' using source /etc/crypto-executor/credentials.env encourages loading exchange API keys directly into an interactive shell environment. That increases the chance of accidental exposure through shell history, debugging output, inherited subprocess environments, or operator misuse.
- ✅ Credentials not visible in `systemctl status` output
- ✅ File protected chmod 600 (root only)
- ✅ Not exposed in process list (`ps aux`)
- ✅ Shared with manual runs: `source /etc/crypto-executor/credentials.env`
---
The notifier sends trade execution and performance details to Telegram, a third-party service, without any guardrail to minimize shared data or require explicit informed consent at the point of use. In a financial trading skill, external transmission of holdings, positions, and performance can leak sensitive financial activity and operational patterns outside the local environment.
The skill places live market and OCO orders automatically with no explicit user confirmation, dry-run default, or mandatory safety interlock. In a plugin/agent context, autonomous trade execution against real exchange credentials is highly dangerous because any bad signal, poisoned dependency, or logic flaw immediately affects real funds.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
## 🚀 Step 1: Binance API Setup
### **Create API Key**
1. Login to https://binance.com
2. Profile → API Management
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Method 1: Use bot
# 1. Send any message to your bot
# 2. Visit (replace YOUR_TOKEN):
https://api.telegram.org/botYOUR_TOKEN/getUpdates
# 3. Find "chat":{"id":123456789}
# 4. Save CHAT_ID
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Method 1: Use bot
# 1. Send any message to your bot
# 2. Visit (replace YOUR_TOKEN):
https://api.telegram.org/botYOUR_TOKEN/getUpdates
# 3. Find "chat":{"id":123456789}
# 4. Save CHAT_ID
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
DRAWDOWN_KILL_PCT=10
sudo chmod 600 /etc/crypto-executor/credentials.env sudo chown root:root /etc/crypto-executor/credentials.env
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
DRAWDOWN_KILL_PCT=10
sudo chmod 600 /etc/crypto-executor/credentials.env sudo chown root:root /etc/crypto-executor/credentials.env
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
DRAWDOWN_KILL_PCT=10
sudo chmod 600 /etc/crypto-executor/credentials.env sudo chown root:root /etc/crypto-executor/credentials.env
No suspicious patterns detected.