Private keys prove identity. Whoever holds one can act as its owner, and often decrypt what was meant for them. MITRE tracks the search for them as T1552.004, Private Keys, a Credential Access technique under Unsecured Credentials. The platforms are Linux, macOS, Network Devices and Windows.
How attackers use it
Adversaries search compromised systems for private key and certificate files. MITRE lists common extensions: .key, .pgp, .gpg, .ppk, .p12, .pem, .pfx, .cer, .p7b and .asc. They also check common key directories, for example ~/.ssh on Unix-like systems and the .ssh folder in a user profile on Windows. Adversary tools may scan for these extensions too.
Three further cases show up on the MITRE page.
- Device keys. When a device is registered to Entra ID, a device key and a transport key are generated to verify the device identity. An adversary with access to the device may be able to export them to impersonate the device.
- Network devices. Private keys may be exported through the device CLI, for example with
crypto pki export. - Passphrases. Some keys need a password to operate, so an adversary may use Input Capture for keylogging, or try to brute force the passphrase offline.
Once stolen, a key can authenticate to remote services like SSH, or decrypt other collected files such as email. A key with no passphrase needs no cracking at all.
How to detect it
MITRE's detection strategy has an analytic for each setting.
- Windows: a process, non-system or user started, that accesses private key files in user profile paths or system certificate stores, followed by network connections or compression activity.
- Linux: user or script access to
~/.sshor other key directories, followed by unusual shell activity or network connections. - macOS: access to user key directories, such as
/Users/*/.ssh, through Terminal, scripting engines or non-default processes. - Network devices: CLI export of private key material, for example
crypto pki export, with an anomalous user session or an AAA role escalation.
The sequence to look for is read, then bundle, then send. Compression or an outbound connection right after a key read is a classic combination.
How to reduce the risk
MITRE lists four mitigations.
- Audit: ensure only authorized keys can reach critical resources, and audit access lists regularly.
- Encrypt Sensitive Information: keep keys on separate cryptographic hardware where possible. On Windows, a TPM can secure keys and other sensitive credential material.
- Password Policies: use strong passphrases on private keys to make cracking hard.
- Restrict File and Directory Permissions: set correct permissions on folders that hold private keys. On Cisco devices, set the nonexportable flag when generating an RSA key pair.
Authorized keys deserve the same attention as private keys. Review which public keys are trusted on your servers, and remove those of people and systems that no longer need access.
Check your own environment
Read-only commands for Linux or macOS.
ls -la ~/.ssh
find ~ -type f \( -name '*.pem' -o -name '*.key' -o -name '*.pfx' -o -name '*.p12' \) 2>/dev/null
- Are private keys readable only by their owner?
- Does every key have a passphrase, or live on hardware?
- Are there stray key files in downloads, backups or project folders?
- Are keys stored in source repositories or images? Scan for them there too.
Secrets scanning finds key material in the same way an adversary's tooling does. The demo below shows it on a sample project.
Click through it at your own pace, or open it full screen.
Quick check
What can an adversary do with a stolen SSH key that has no passphrase?
Authenticate to the remote services it unlocks right away, with nothing to crack.
What does the nonexportable flag on Cisco devices do for this technique?
Set when the RSA key pair is generated, it helps block the key from being exported through the CLI.
Sources
- MITRE ATT&CK, Unsecured Credentials: Private Keys: https://attack.mitre.org/techniques/T1552/004
