Cryptominers have developed a sophisticated persistence technique that bypasses traditional file monitoring by manipulating systemd's file descriptor interface. Instead of dropping unit files to /etc/systemd/system/ or /run/systemd/system/, attackers inject services directly through /proc/1/fd/, creating legitimate systemd units that security tools never see.
This attack vector exploits a fundamental aspect of systemd's architecture: unit files don't need to exist on disk to be active. systemd maintains references to active units through file descriptors accessible via /proc/1/fd/, and attackers have learned to abuse this mechanism.
Understanding PID 1 File Descriptor Architecture in systemd
When systemd loads a unit file, it creates file descriptors that remain open for the lifetime of the service. These descriptors appear in /proc/1/fd/ as numbered symbolic links pointing to the original unit files. However, systemd doesn't require these files to persist on disk once loaded.
How /proc/1/fd Links to Active systemd Units
A typical systemd installation shows dozens of file descriptors in /proc/1/fd/:
ls -la /proc/1/fd/ | grep -E '\.service|\.timer|\.socket'
lrwx------ 1 root root 64 Feb 15 10:23 15 -> /etc/systemd/system/ssh.service
lrwx------ 1 root root 64 Feb 15 10:23 18 -> /run/systemd/system/cron.service
lrwx------ 1 root root 64 Feb 15 10:23 22 -> /tmp/malicious-unit.service (deleted)That final entry reveals the attack: a service loaded from /tmp/ that's since been deleted. The unit remains active because systemd holds the file descriptor, but the original file has vanished.
The Attack Vector: Injecting Units Without Filesystem Writes
Attackers create temporary unit files, use systemctl link to register them with systemd, then delete the original files. The services persist because systemd maintains open file descriptors to the deleted files.
Memory-Based Unit Creation Through File Descriptors
The attack sequence follows this pattern:
- Create a temporary unit file with legitimate-looking metadata
- Use
systemctl link /tmp/temp-service.serviceto register it - Start the service with
systemctl start temp-service - Delete the original file with
rm /tmp/temp-service.service - The service continues running with only a
/proc/1/fd/reference
Attackers often name these services to blend with system units: systemd-journal-upload.service or networkd-dispatcher.service. The names appear legitimate in process lists and service status commands.
Why Traditional File Monitoring Fails
File integrity monitoring tools watch standard systemd directories like /etc/systemd/system/ and /usr/lib/systemd/system/. They never see these injected units because the attack bypasses filesystem writes entirely. Even systemctl list-unit-files won't show them since the files no longer exist.
The injected services appear in systemctl list-units output alongside legitimate services, making detection difficult without specific analysis of file descriptor patterns.
Real-World Detection: Monitoring systemd's File Descriptor State
Detecting this attack requires understanding normal /proc/1/fd/ patterns and identifying anomalies that indicate injection attempts.
Baseline Analysis of Normal /proc/1/fd Patterns
Legitimate systemd file descriptors typically point to:
/etc/systemd/system/for custom services/usr/lib/systemd/system/for distribution-provided units/run/systemd/system/for runtime-generated services
Any descriptor showing (deleted) or pointing to unusual locations like /tmp/, /var/tmp/, or user home directories indicates potential injection.
Identifying Anomalous Unit Injection Signatures
Monitor for file descriptors with these characteristics:
- Links pointing to deleted files (containing "deleted" in the target)
- References to temporary directories (
/tmp/,/var/tmp/) - Unit files in non-standard locations (
/home/,/opt/) - Services with legitimate-sounding names but suspicious file descriptor origins
Combine this with process analysis - check if services with anomalous file descriptors are consuming unusual CPU cycles or making network connections typical of cryptominers.
Prevention and Monitoring Implementation
Beyond detection, implement monitoring that tracks systemd's file descriptor state changes in real-time. Server Scout's service monitoring features include systemd unit validation that can identify these injection attempts as they occur.
Set up periodic analysis of /proc/1/fd/ patterns. Create alerts for new file descriptors that don't follow expected systemd file location conventions. Monitor for services that appear in systemctl list-units but don't have corresponding files in standard systemd directories.
Considering broader infrastructure security, this attack vector represents why traditional file monitoring approaches fall short against advanced persistence techniques. For teams managing complex systemd environments across multiple servers, socket-level monitoring approaches provide additional detection capabilities that complement file descriptor analysis.
The sophistication of this attack demonstrates why compliance monitoring frameworks need to evolve beyond file-based security controls to include process and file descriptor validation.
This persistence technique represents a significant evolution in cryptominer deployment strategies. Traditional security tools focus on file modifications and network behaviour, but this approach operates entirely within legitimate systemd functionality. Understanding and monitoring these file descriptor patterns becomes essential for maintaining system integrity in production environments.
FAQ
Can this attack work without root privileges?
No, systemctl link and systemctl start both require root privileges or appropriate sudo access. However, if an attacker gains temporary root access, they can establish persistence that survives the initial compromise detection.
Do systemd-based containers face the same risk?
Container environments using systemd as PID 1 are vulnerable, but the attack scope is limited to the container. However, if the container has host filesystem access or privileged capabilities, the technique could potentially affect the host system.
How can I check if my systems are already compromised using this method?
Run ls -la /proc/1/fd/ | grep deleted to identify any deleted unit files. Cross-reference the output of systemctl list-units with actual files in systemd directories to find units that exist in memory but not on disk.