T1552 Unsecured Credentials — Detection & Response
Adversaries may search compromised systems to find and obtain insecurely stored credentials. These credentials can be stored and managed in various locations depending on the operating system and application: plain text files, configuration files, source code, container images, environment variables, and cloud instance metadata services.
Coverage at a glance
- Detections shipped
- 4
- Avg. verdict time
- < 5 min
- Data sources
- 4+
Threat context
How adversaries use T1552 Unsecured Credentials — Detection & Response
Adversaries may search compromised systems to find and obtain insecurely stored credentials. These credentials can be stored and managed in various locations depending on the operating system and application: plain text files, configuration files, source code, container images, environment variables, and cloud instance metadata services.
Credential exposure is endemic in most enterprise environments. Developers commit secrets to code repositories, hardcode credentials in configuration files, or print them in log output. Attackers who gain any foothold — via phishing, exploitation, or supply chain compromise — immediately scan for credentials using automated tools (truffleHog, gitleaks, GittyLeaks) or manual techniques like searching for strings matching AWS key patterns or common password environment variable names. Cloud instance metadata service (IMDS) access is a particularly dangerous sub-technique: any code running on an EC2 instance can call the metadata endpoint to retrieve the IAM role credentials without any additional authentication.
Detections ManySignal ships
Ready-to-deploy detection rules
| Rule name | Severity | Data source |
|---|---|---|
| EC2 Instance Profile Credential Used from External IP Temporary credentials issued via the EC2 Instance Metadata Service are used from an IP address outside the expected AWS IP ranges — SSRF or IMDS exfiltration indicator. | Critical | AWS CloudTrail |
| Git Repository Secret Scanning Match A newly committed file matches a known secret pattern (AWS access key, Stripe key, private key header) — credential exposure in source code. | High | GitHub / GitLab Secret Scanning |
| Credential File Access by Non-Application Process A process other than the expected application binary reads a credentials file (~/.aws/credentials, .env, settings.py) — potential local credential harvesting. | High | CrowdStrike / SentinelOne |
| kubectl exec to Production Pod Followed by env Command An interactive kubectl exec session runs 'env' or 'printenv' in a production pod — environment variable harvesting for secrets. | High | Kubernetes Audit Logs |
Related techniques and tactics
T1078 Valid Accounts — Detection & Response
ATT&CK Technique
T1110 Brute Force — Detection & Response
ATT&CK Technique
T1566 Phishing — Detection & Response
ATT&CK Technique
T1059 Command and Scripting Interpreter — Detection & Response
ATT&CK Technique
T1053 Scheduled Task/Job — Detection & Response
ATT&CK Technique
T1548 Abuse Elevation Control Mechanism — Detection & Response
ATT&CK Technique
T1068 Exploitation for Privilege Escalation — Detection & Response
ATT&CK Technique
T1134 Access Token Manipulation — Detection & Response
ATT&CK Technique
T1098 Account Manipulation — Detection & Response
ATT&CK Technique
T1136 Create Account — Detection & Response
ATT&CK Technique
T1556 Modify Authentication Process — Detection & Response
ATT&CK Technique
T1621 Multi-Factor Authentication Request Generation — Detection & Response
ATT&CK Technique
T1552 Unsecured Credentials — Detection & Response: frequently asked questions
How common is credential exposure in source code?
Extremely common. Studies consistently find that a significant percentage of public repositories contain exposed credentials, and private repositories in enterprise settings frequently contain hardcoded credentials committed years ago. ManySignal integrates with GitHub, GitLab, and Bitbucket secret scanning to surface these.
What is IMDS and why is it a security concern?
The Instance Metadata Service (IMDS) is an AWS endpoint (169.254.169.254) accessible from any code running on an EC2 instance. It returns the temporary IAM credentials assigned to the instance role. SSRF vulnerabilities in web applications can be exploited to call the IMDS and steal these credentials without authenticating.
What is IMDSv2 and does it eliminate the risk?
IMDSv2 requires a PUT request with a TTL-bound session token before credential retrieval, preventing simple SSRF-based IMDS attacks that use GET requests. It significantly reduces the risk but does not eliminate it if the SSRF can perform arbitrary PUT requests.
Can ManySignal detect secrets in Slack or Teams messages?
T1552.008 covers secrets in chat messages. ManySignal ingests Slack and Teams audit events, but chat content scanning requires the DLP integration in those platforms. Alerts from Slack/Teams DLP policies are ingested by ManySignal and correlated with the sender's identity.
How does ManySignal handle private key theft (T1552.004)?
Private key file access by unexpected processes is detected via endpoint telemetry. Private key usage from a new IP or at an unusual time (SSH, code signing) is detected via authentication log analysis.
Does ManySignal detect container environment variable harvesting?
Yes. kubectl exec commands that run env/printenv in production pods appear in Kubernetes audit logs as anomalous interactive container access. ManySignal treats this as a high-severity credential access event.
What is the risk of credentials in bash history (T1552.003)?
Commands like 'export AWS_ACCESS_KEY_ID=...' or 'curl -H Authorization: Bearer ...' are stored in shell history files. An attacker with file system access can read ~/.bash_history to extract credentials used in previous sessions.
How does ManySignal correlate a secret scanning alert with an actual access event?
When GitHub secret scanning fires on a pushed credential, ManySignal correlates the detected credential type with subsequent anomalous API calls using matching credential formats. This links the exposure event to the exploitation event in the investigation timeline.
What should organisations do immediately when a cloud credential is found exposed?
1) Identify the exposure window (when was it first committed or exposed). 2) Rotate the credential immediately. 3) Review CloudTrail/audit logs for that credential during the exposure window for unauthorised use. 4) Assess what the credential had access to. ManySignal accelerates steps 3-4.
Does ManySignal support integrations with secret scanning tools like truffleHog?
ManySignal ingests findings from GitHub Secret Scanning, GitLab Secret Detection, and Bitbucket's equivalent natively. Custom tools like truffleHog can emit findings via webhook to ManySignal's generic alert ingestion endpoint.
See the agentic SOC in action
Watch AI agents work a real alert queue — verdicts, evidence, and confidence scores included. In-house SOC or MDR, your call.