MAL-PERSIST Persistence-Mechanism Writes
A package almost never needs to install a persistence mechanism. Planted malware does, writing itself into a boot, login or scheduler surface so it survives a reboot, a new shell or a re-clone.
What Vulkro detects
MAL-PERSIST-001 fires when a persistence location and a write or append fall within a few lines of each other in the same file. Locations:
~/.ssh/authorized_keys- cron (
crontab -,/etc/cron.d,/etc/crontab,/var/spool/cron) - a systemd unit or
systemctl enable - a macOS LaunchAgent or LaunchDaemon plist,
launchctl load - shell rc files (
~/.bashrc,~/.zshrc,~/.bash_profile,~/.zprofile,~/.profile) and/etc/rc.local - a Windows registry Run key or
reg add
A path with no nearby write does not fire (an SSH tool reading ~/.ssh/config is fine). Severity is always High. Confidence is High for a strong install primitive (>>, Python open(.., 'a'), crontab -, reg add, systemctl enable, appendFile) and Medium for a weaker write (a bare echo, a generic .write().
This is co-location, not data flow. It scans shell, JS, TS, Python and PowerShell, and never certifies code safe.
How to fix
- Check the named surface before and after any run (
crontab -l,ls ~/.ssh/authorized_keys,systemctl list-unit-files,launchctl list) and remove entries you did not create. - Software that must run at login should ask, not write itself in during install.
References
See also: Confidence model.
This page is generated by vulkro rules export <out-dir> from Vulkro's built-in detector catalogue. Edits made by hand are overwritten on the next regeneration.