T06 · System Persistence
- Location
references/alert-workflow.md:32- Finding
Persistent Scheduled Monitoring Task
- Content
View full analysis
90%, send Feishu notification. Track cooldown to avoid duplicate alerts.", schedule="*/5 * * * *", name="Game Server Alert Monitor", skills=["game-ops-monitor"], deliver="origin") ``` ### Technical Analysis The documented setup creates a recurring Agent job that runs every five minutes and survives the interaction in which it was created. The task repeatedly queries all game servers and may initiate notifications through external webhook integrations. Scheduled monitoring is consistent with the optional alerting workflow, and the behavior is not hidden. Nevertheless, it exceeds the minimum privileges needed for the Skill's primary on-demand monitoring functionality. The instructions do not require explicit confirmation immediately before persistence is established, define an expiration time, restrict the job to a least-privilege identity, or provide a corresponding removal procedure. Because the scheduled prompt invokes the Skill again in future sessions, later changes to the Skill, its configuration, or its referenced notification behavior could affect an already-installed job. ### Attack Path 1. A user follows the alert setup instructions and creates the cron job. 2. The Agent platform stores the job across sessions. 3. Every five minutes, the job invokes `game-ops-monitor`. 4. The Skill queries operational data for all configured game servers. 5. When threshold conditions are met, results may be transmitted through the configured Feishu or DingTalk integration. 6. The process continues until an administrator manually identifies and removes the job. ### Impact Assessment The persistence grants recurri ...[truncated 493 chars]- Remediation
View remediation
