T07 · Tool Hijacking and Spoofing
- Location
scripts/lora_monitor.py:18- Finding
Writable Workspace Module Can Hijack Monitor Execution
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a real LoRa scanner package, but it needs Review because it can continuously capture radio packet contents, forward them through an agent/Telegram workflow, and uses unsafe persistence/import patterns.
Install only for authorized RF monitoring. Before use, remove the writable workspace import override, pin dependencies, run the monitor under a dedicated low-privilege account, add explicit stop instructions, and change Telegram delivery to send structured metadata by default while treating any packet payload as untrusted data.
scripts/lora_monitor.py:18Writable Workspace Module Can Hijack Monitor Execution
scripts/lora_monitor.py:207Untrusted Over-the-Air Packet Content Is Passed into an AI Agent Turn
SKILL.md:33Third-Party Dependencies Are Installed Without Exact Version or Integrity Pinning
The declared description is for an embedded RF scanner/sniffer system with hardware control and monitoring/reporting features. The supplied code does not implement scanning, radio hardware access, ESP32/LilyGo behavior, OLED updates, reporting schedules, or alert transport. Its primary purpose is materially different: it decodes already-captured LoRa packet payloads from hex strings and formats human-readable summaries. Although both relate to LoRa and Telegram formatting appears as a support function, the actual code is a decoder utility rather than a scanner. This is a clear description-behavior mismatch.
The declared description describes embedded firmware or a multi-component RF monitoring system centered on a LilyGo T3 LoRa scanner with display, reporting, and alerting features. The supplied code is instead a simple offline analysis utility for HackRF sweep CSV output. It reads a file from disk, aggregates signal values by frequency bin, estimates a noise floor using the 15th percentile of average bin values, and prints notable peaks above a threshold. While HackRF is mentioned in both, the actual code does not perform scanning, LoRa-specific detection, hardware control, OLED updates, serial reporting, or Telegram notifications. This is a clear material mismatch in primary purpose and capabilities.
The README explicitly promotes sending captured LoRa packet contents, decoded fields, and hex dumps to Telegram, but provides no warning that intercepted radio traffic may contain personal, device, or operational data. In an RF reconnaissance/sniffer context, exfiltrating captured packet data to a third-party messaging platform materially increases privacy, compliance, and unauthorized disclosure risk.
The skill documents behavior that writes files and logs (lora_alert.txt, lora_hits.json, lora_monitor.log) but does not declare an explicit tool scope such as allowed file-write permissions. In an agent environment, undeclared write capability weakens containment and makes it harder to review where data may be persisted or overwritten.
The description uses broad activation language around RF monitoring and reconnaissance, which could cause the skill to trigger for general or ambiguous RF-related requests. In agent systems, overbroad invocation increases the chance of unintended use of hardware-monitoring workflows and unnecessary collection or persistence of radio-derived data.
The documented use of nohup ... & creates a background process that persists beyond the initiating session. In an agent or shared host context, unattended persistence can continue serial monitoring, file generation, and device interaction after the user expects execution to have stopped, which increases operational and privacy risk.
arduino-cli upload --fqbn esp32:esp32:esp32 --port /dev/ttyACM0 ~/Arduino/LoRaCADScan
# 2. Start the Pi monitor (background)
nohup python3 scripts/lora_monitor.py > lora_monitor.log 2>&1 &
# 3. Set up Telegram alert cron (OpenClaw)
# See references/setup.md for cron job configuration
This workflow explicitly instructs users to capture raw IQ data with HackRF and demodulate it to identify signal types beyond LoRa CAD scanning. That expands the skill from narrow LoRa channel detection into general-purpose RF interception and analysis, which can facilitate monitoring of unrelated communications and increases dual-use risk.
The documentation lists amateur, satellite, beacon, and other non-LoRa allocations and provides interpretation tips for those signals, which materially broadens the reconnaissance value of the skill beyond its stated LoRa scanner purpose. In context, this makes the skill more dangerous because it helps users identify and focus on third-party services that are unrelated to LoRa monitoring.
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.
cp scripts/lora_monitor.py /path/to/workspace/
# Run in background
nohup python3 lora_monitor.py > lora_monitor.log 2>&1 &
# Check it's running
tail -f lora_monitor.log
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.
cp scripts/lora_monitor.py /path/to/workspace/
# Run in background
nohup python3 lora_monitor.py > lora_monitor.log 2>&1 &
# Check it's running
tail -f lora_monitor.log
The file advertises 15-minute reports via Serial and Telegram forwarding but provides no in-code warning that scan results, including potentially sensitive detections or captured packet details, may be transmitted off-device. That omission is risky because users may deploy the scanner assuming local-only operation while a connected pipeline forwards reconnaissance data externally.
The code serializes captured LoRa packet payload bytes in hex and emits them over Serial, which can expose third-party RF communications content to any attached host, logger, or downstream automation without explicit user disclosure or consent safeguards. In this skill’s context, the risk is elevated because the scanner is explicitly designed for RF reconnaissance and integration into reporting pipelines, making silent exfiltration or retention of intercepted data more likely.
The text explicitly promotes RF reconnaissance without strong opt-in, authorization, or jurisdiction-specific safeguards beyond a brief legal disclaimer later in the file. That framing can normalize potentially sensitive monitoring activity and make misuse more likely in contexts where radio surveillance is regulated.
The security/privacy section claims outputs stay within the local workspace, but the quick-deploy command writes lora_monitor.log to the current directory and also references Arduino sketch paths outside the workspace. Misstating data locality can cause operators to mishandle sensitive RF/device-identifying data under false assumptions.
This markdown file includes a command that writes captured IQ data to /tmp/iq.raw, which is a file write affecting local storage. The document presents the command as a straightforward step but does not warn the user that it will create a potentially large recording file or leave captured signal data on disk.
This markdown setup guide instructs the agent to "read it, send to user via Telegram, delete the file" for lora_alert.txt. Because the file deletion affects user/workspace data and the description does not explicitly warn the user about this destructive behavior beyond the embedded instruction itself, it lacks a clear user-facing warning called for in markdown guidance.
No suspicious patterns detected.