Five Malicious Rust Crates Posed as Time Utilities to Steal .env Files

Security researchers at Socket discovered five malicious Rust crates on the crates.io package registry, all disguised as innocent time-related utilities while secretly exfiltrating .env files containing developer credentials and API keys.

TL;DR

• What happened: Five Rust packages stole .env files containing API keys and secrets
• Who's affected: Developers who installed chrono_anchor, dnp3times, time_calibrator, time_calibrators, or time-sync
• Severity: High - .env files typically contain production credentials
• Action required: Rotate all keys/tokens if any package was installed; audit CI/CD pipelines

The Malicious Packages

The five identified crates are:

• chrono_anchor
• dnp3times
• time_calibrator
• time_calibrators
• time-sync

All five were published between late February and early March 2026, impersonating functionality related to time synchronization with timeapi.io. Socket researcher Kirill Boychenko noted that while the packages "pose as local time utilities, their core behavior is credential and secret theft."

The attacker registered a lookalike domain, timeapis[.]io (note the extra 's'), to receive stolen data.

What Makes .env Files So Valuable

The .env file format has become the standard way for developers to configure applications without hardcoding secrets. A typical .env file might contain:

DATABASE_URL=postgres://user:password@host/db
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
STRIPE_SECRET_KEY=sk_live_xxxxx
GITHUB_TOKEN=ghp_xxxxxxxxx

By stealing these files, attackers gain immediate access to cloud services, databases, payment processors, and code repositories. It's a one-stop shop for compromising an entire organization's infrastructure.

Attack Methodology

Four of the five packages used straightforward exfiltration. During installation or first import, the code would:

1. Locate .env files in the project directory and home folder
2. Read their contents
3. POST the data to the attacker's lookalike domain

The fifth package, chrono_anchor, showed more sophistication. The malicious logic was embedded within a file named "guard.rs" and invoked through a helper function, adding a layer of obfuscation that helped it evade initial detection.

Socket's analysis suggests a single threat actor operated all five packages based on consistent exfiltration methodology and shared infrastructure.

CI/CD Pipeline Risk

The danger extends beyond individual developer machines. Modern CI/CD pipelines often:

• Pull dependencies automatically on each build
• Store secrets as environment variables accessible during builds
• Run with elevated privileges to deploy production code

If a malicious crate entered a pipeline with deployment credentials, attackers could gain access to production infrastructure, artifact repositories, and cloud consoles. Supply chain compromises like this have enabled previous attacks on enterprise environments.

Response and Remediation

RustSec and the GitHub Advisory Database flagged the packages, and crates.io security yanked four of them shortly after publication. The chrono_anchor package's additional obfuscation allowed it to remain listed longer before identification and removal.

If you installed any of these packages:

1. Assume compromise - Treat all secrets in accessible .env files as leaked
2. Rotate everything - API keys, database passwords, cloud credentials, tokens
3. Audit CI/CD logs - Check for unexpected outbound connections during builds
4. Review installed dependencies - Use cargo tree to identify the full dependency graph
5. Restrict network access - Consider denying outbound connections from build environments by default

A Growing Pattern

This incident follows a broader trend of supply chain attacks targeting developer ecosystems. We've covered similar campaigns against npm with North Korean actors and NuGet with typosquatted packages.

The Rust ecosystem has historically been considered more security-conscious than some alternatives, but crates.io faces the same challenges as any open package registry: rapid growth, volunteer moderation, and attackers who study legitimate naming patterns.

The timeapi.io impersonation was clever. Developers searching for time-related utilities wouldn't immediately notice the extra letter in the exfiltration domain, and the package names themselves sounded plausible.

Defensive Measures for Teams

Organizations can reduce supply chain risk through several practices:

Dependency Pinning: Lock to specific package versions rather than accepting any update. This limits exposure when a previously-safe package is compromised.

Network Monitoring: Build environments that make unexpected HTTP connections warrant investigation.

Private Mirrors: Enterprise teams can proxy crates.io through internal infrastructure that scans packages before allowing access.

Least Privilege Secrets: CI/CD jobs should only have access to credentials needed for their specific function. A build job doesn't need production database access.

Regularly Rotate Credentials: If secrets do leak, short validity periods limit the damage window.

FAQ

How do I check if I installed these packages?

Run cargo tree in your project to see all dependencies. Search your Cargo.lock files across repositories for the package names. Check CI/CD build logs for any installation of the flagged crates.

What if I only installed one briefly for testing?

The exfiltration could trigger on first import. If the package was installed in any environment with .env files containing real credentials, rotate those credentials. Brief exposure is still exposure.