Cron & Scheduling

Security checks across malware telemetry and agentic risk

Overview

This is a coherent cron/systemd scheduling guide, but users should notice that it includes commands for persistent and privileged scheduled tasks.

This skill appears safe as a scheduling reference, but treat cron and systemd changes as persistent system changes: review commands before running them, back up existing crontabs, confirm the user/service account, and disable timers or jobs you no longer want.

VirusTotal

64/64 vendors flagged this skill as clean.

View on VirusTotal

Risk analysis

Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.

#
ASI02: Tool Misuse and Exploitation
Medium
What this means

A user or agent following the example incorrectly could delete existing scheduled jobs.

Why it was flagged

The guide documents a command that can remove all cron jobs for a user. It is clearly labeled with a caution and is relevant to crontab management, but misuse could disrupt scheduled tasks.

Skill content
# Remove all cron jobs (be careful!)
crontab -r
Recommendation

Confirm the target crontab and make a backup with `crontab -l > backup.txt` before removing or replacing scheduled jobs.

#
ASI03: Identity and Privilege Abuse
Medium
What this means

Using these commands can modify jobs that run as another system user, which may affect services or production workloads.

Why it was flagged

The skill includes privileged administration of another user's crontab. This is purpose-aligned for scheduling administration, but it crosses user/account boundaries.

Skill content
# Edit another user's crontab (root)
sudo crontab -u www-data -e
Recommendation

Use privileged cron or systemd commands only when the user explicitly requests that scope and understands which account or service will run the job.

#
ASI10: Rogue Agents
Medium
What this means

Scheduled tasks may run later, at startup, or after a reboot, potentially causing unexpected changes if forgotten.

Why it was flagged

The guide covers mechanisms that continue or resume execution after reboot or logout. Persistence is central to scheduling, but users should be aware that jobs may keep running after the initial setup.

Skill content
@reboot    /path/to/script.sh   # Run once at startup
...
Persistent=true
...
nohup bash -c "sleep 7200 && /opt/scripts/task.sh" &
Recommendation

Track installed cron entries, systemd timers, and queued at/nohup jobs, and remove or disable them when they are no longer needed.