Detecting T1552 Unsecured credentials

How T1552 unsecured credentials shows up in intrusions

For a SOC lead, T1552 Unsecured credentials means an attacker did not need to break anything to obtain a password or key. The secret was already sitting in a file, script, repository, cloud metadata service or container configuration, readable by anyone who reached that system. After a foothold, the adversary searches for these secrets and reuses them to move further. In MITRE ATT&CK, the technique falls under Credential Access (TA0006), a tactic defined as "The adversary is trying to steal account names and passwords." This page targets Enterprise ATT&CK version 20.0. The technique's eight sub-techniques group the places where secrets are typically left: files and other unprotected storage, containers, cloud instance metadata, private keys, shell history and group policy settings. Each family has a different owner and a different check, which is why this page treats them separately.

Intrusions usually surface these secrets during the discovery and lateral movement phases that follow initial access. Typical locations include developer workstations, shared drives, deployment scripts, configuration files committed to source repositories, CI runners and virtual machines that can query their own cloud metadata endpoint. Containerized workloads often expose orchestration credentials through mounted configuration. The search itself looks much like ordinary administration, so the signal that matters is a successful authentication made with a credential that should not have been reachable from that host. Before writing any detection, ask your platform and development teams to list where service account credentials, API keys and private keys are stored in each environment. Confirm the current sub-technique descriptions against the ATT&CK 20.0 entry, since releases can rename, deprecate or revoke techniques.

The reason this technique is hard to catch is that the credential is valid. A login with a service account or key recovered from a script passes authentication checks, so detection depends on file access, process creation and user account authentication telemetry, along with knowing which identities should authenticate from which hosts. Start with a short list of high-value locations, enable file access auditing on those paths where your platform supports it, and baseline which service identities normally log on where. Then review the mitigations mapped to this technique: User Training (M1017) addresses how staff avoid embedding secrets in files and chat, and Audit (M1047) addresses the logging that makes later review possible. Record these decisions in your detection backlog so the cyber range exercise later on this page tests the same locations.

Which telemetry reveals T1552 and which open-source tool collects it

This table maps the ATT&CK data components referenced for Credential Access techniques to the T1552 signals a defender should look for and the open-source collector that usually gathers each one. Read each row as a starting point, then confirm the data component IDs and platform coverage against the ATT&CK version your detection content targets, since releases can rename or revise mappings.

Data component	Signal to look for	Open-source collector	Platform coverage
Process Creation (DC0032)	Command lines or scripts that read configuration files, environment variables or secret stores for embedded credentials	Wazuh agent, Velociraptor, Sysmon with Wazuh	Windows, Linux
File Access (DC0055)	Reads of files commonly holding plaintext secrets, such as configuration, deployment or shell history files	Wazuh file integrity and audit rules, Velociraptor hunts	Windows, Linux, IaaS hosts
User Account Authentication (DC0002)	Logons using service or shared accounts from unexpected hosts, or repeated failures after a credential is found	Wazuh agent, Windows Security logs, Zeek authentication logs	Windows, Linux, SaaS identity providers
Application Log Content (DC0038)	Secrets or tokens written into application, CI or SaaS audit logs, and unusual API calls using static keys	Wazuh log collection, Security Onion log ingestion, cloud audit log forwarding	SaaS, IaaS, Linux
Network Traffic Content (DC0085)	Credentials or tokens sent in cleartext or to unexpected destinations over HTTP or other protocols	Zeek, Suricata with custom rules	Linux, Windows, SaaS (via egress)
Cloud audit and key usage records	Access keys or instance metadata credentials used from new IP ranges or outside expected automation	Cloud-native audit logs forwarded to Wazuh or Security Onion, Velociraptor for host artifacts	IaaS
Confirm mapping before use	Check which DC IDs and detection strategies the target ATT&CK version lists for T1552 and its sub-techniques	Enterprise ATT&CK STIX bundle for the version you target	All platforms listed

Detection logic for T1552 that SOC teams can tune

The ideas below cover where unsecured credentials sit on endpoints, in workloads, and inside SaaS and IaaS control planes. Each one pairs a detection logic with the thresholds to tune and the benign activity that will trigger it first, so the alert stays useful after the first week of tuning.

File access to credential paths

Alert when a process outside an approved list opens known credential-bearing files, such as shell history, cloud CLI configuration, SSH private keys, or .netrc files. Start with a short list of paths you control and a baseline of which accounts and processes read them today. Tune by user, parent process, and host role. Expect configuration management agents, backup agents, and CI runners to read these files on schedule, so allowlist them by signed binary and service account rather than by path alone.

Content searches for secret patterns

Flag processes that scan file contents for secret-like strings, such as key headers, token prefixes, or high-entropy assignments, across many files in a short window. The signal is breadth: one search across a repository is normal for a secret scanner, while the same pattern run by an interactive shell across home directories is not. Tune on file count per minute and the number of distinct directories touched. Common false positives come from developer tooling, pre-commit hooks, and security scanners that run on schedule.

Instance metadata reads

Alert when a process other than the expected agent or init component requests credentials from the cloud instance metadata endpoint. Map which runtimes legitimately fetch role credentials, such as an application container or a configuration tool, and record the process path and user for each. Tune by process, user, and the time since boot, because a shell that queries the endpoint shortly after login is a stronger signal than a long-running service. Confirm with your cloud provider which metadata versions and hop limits your fleet uses before you write the rule.

Container secret mount access

Watch for reads of mounted secret volumes inside containers by processes that do not belong to the workload, and for new mounts of secret objects into pods outside the deployment pipeline. Pair file access events with orchestration audit logs so you can tell whether a secret was mounted by a deployment or read by an unexpected exec session. Tune by namespace and service account. Helm charts, sidecar injectors, and operators that rotate secrets are frequent sources of benign reads, so inventory them before alerting.

Unusual secret retrieval in SaaS and IaaS

Correlate secret manager and identity provider audit events where a principal retrieves secrets it has not read before, from a new source address, or at an unusual hour. Build the baseline from the last several weeks of activity for each service account, then set thresholds on volume and on new secret names. Backup agents, rotation jobs, and CI runners will dominate the baseline, so label them and alert on deviations from their own history. Confirm which audit events your provider logs and how long they are retained before you depend on them.

Building T1552 detections as Sigma rules in Wazuh

Expressing T1552 Unsecured Credentials detections as Sigma rules lets a team write each detection idea once, tag it with the right ATT&CK technique or sub-technique ID, and convert it for the SIEM or log pipeline it runs in. Start with one rule per sub-technique family rather than one catch-all rule, so that a hit on, for example, a cloud token file in a Linux host group points to a specific sub-technique and a specific response. Each rule should name its logsource (for example, a Windows Security or Sysmon event channel, a Linux audit source, or a SaaS or cloud audit feed), its detection logic in plain terms, and its tags field carrying the technique ID such as attack.t1552 and the sub-technique suffix where one applies. Confirm the exact sub-technique IDs against the ATT&CK 20.0 STIX bundle before you tag anything, since the set of sub-techniques under T1552 is what your coverage report will be measured against.

In Wazuh, Sigma-derived logic usually lands as custom decoders and rules in the local rules directory, or as searches in the indexer, depending on how your deployment converts Sigma. Confirm with your Wazuh version which conversion path it supports and how file access and process telemetry reach the manager, because the File Access and Process Creation data components depend on auditd, Sysmon or agent configuration you control. If the rules go through a Security Onion pipeline, check the same thing there. Before any rule reaches production, baseline legitimate secret access per host group: build agents, configuration management, backup jobs and developer tooling all read files that look like credentials. Record those reads as allowlist entries scoped to a host group and a process path, not to a whole environment, and keep every allowlist and rule file in version control with review, so that a change to an exception is visible in a commit history.

Record the ATT&CK version each rule targets, for example in a attack_version field or a comment header, and store it alongside the rule in version control. MITRE releases new ATT&CK versions on a regular cycle, and releases can rename, deprecate or revoke techniques, so a rule that was correct for one version may point at a retired ID later. When you move to a newer version, diff the technique list against the STIX bundle for that release, update tags, and rerun your coverage check. Ask your Wazuh or Security Onion provider and your Sigma tooling maintainers which ATT&CK version their bundled rules target, because bundled rules are often older than the framework they claim to cover.

How to validate that T1552 detections fire

This sequence proves, in a lab or cyber range, that the detections for T1552 Unsecured Credentials fire on the right telemetry, reach the SIEM within a measured time and carry the fields analysts need. It ends with a written record of gaps and the fixes assigned to each one.

Approve and scope the emulation in writing
Before any activity starts, the CISO or security lead signs a written emulation scope that names the T1552 sub-techniques in scope, the Windows, SaaS, IaaS and Linux systems involved, the range or lab boundary, the named operators and the stop conditions. Confirm the ATT&CK version the detection mappings target, since releases can rename or revoke techniques. The step is complete when the signed scope is filed with the change record.
Select the sub-techniques and map expected telemetry
The detection engineer lists each sub-technique in scope and the data components expected to show it, such as File Access, Process Creation and User Account Authentication, drawn from the ATT&CK detection strategies for that version. For each one, write down the log source, the expected event types and the fields that should appear, such as host, user, process and timestamp. The step closes when this expectation sheet is reviewed and agreed by the detection team and the SOC lead.
Place decoy credential artifacts in controlled locations
The range team places decoy credential-like artifacts in locations that match the scope, such as configuration files, cloud metadata-style stores and shared folders on test systems. Each decoy is tagged with a unique identifier so later alerts can be traced back to it. Record each location, owner and identifier in the change record. The step is complete when an inventory of every decoy exists and no decoy sits on a production system or contains real secrets.
Run the planned activity under a change record
The operator runs only the activity described in the approved scope, under an active change record, while a second person observes and logs start and end times. The observer notes any deviation from the plan and halts the exercise if a stop condition is met. The step closes with a timestamped activity log that matches the scope, which is the baseline for every later comparison.
Confirm alerts reach the SIEM
The SOC checks the SIEM and the alerting platform, such as Wazuh, Security Onion or the team's chosen stack, for alerts tied to the run identifier and decoy identifiers. Confirm each expected event arrived from the agent or forwarder, was parsed correctly and matched the detection rule intended for it. Where an alert is missing, check the collection path before concluding the rule failed. The step is done when each expected detection is marked as fired, partially fired or missing.
Measure time to alert and field completeness
For each fired detection, the analyst records the time between the logged activity and the alert, and whether the expected fields are present and populated, such as user, host, process and artifact name. Compare these results with the expectation sheet from the planning step. The step closes with a table of time to alert, field presence and any mismatch, which becomes the measured baseline for the detection.
Record gaps and assign remediation
The team writes up each gap, such as a missing log source, a delayed alert, an absent field or a rule that never fired, and assigns an owner and a retest date to each. Gaps caused by the mitigations in scope, including User Training and Audit configuration, are logged separately so the audit settings can be verified. The step is complete when the report is reviewed by the CISO, filed with the change record and the decoys are removed and verified as cleaned up.

Preventive controls mapped to ATT&CK mitigations

T1552 Unsecured Credentials is less about an attacker breaking in and more about secrets sitting where anyone with access can read them. The mitigations below address that exposure from different angles: how people handle secrets, where secrets are stored, who can reach them, and whether storage locations are watched. Use the ATT&CK version your team targets to confirm the current mapping before you rely on it.

User training on secret handling

User Training (M1017) addresses the habit of pasting passwords, API keys or tokens into scripts, tickets, chat channels, wikis and configuration files. Training should be specific to the platforms your engineers use, such as source repositories, CI variables, shared drives and collaboration tools, and should explain what to do instead, such as requesting access to a vault entry. Check that onboarding and periodic refreshers include examples from your own environment, and measure whether the guidance is followed through spot checks rather than completion rates alone.

Audit where secrets are stored

Audit (M1047) is the control that tells you whether the other controls are working. For T1552, the useful question is where credentials, keys and tokens currently live, including configuration files, environment variables, container images, cloud instance metadata, browser stores and shared folders. Schedule recurring discovery scans, record owners for each finding, and feed results into a remediation queue. Ask any vendor or partner to show how audit logs of secret access are retained and reviewed in your environment.

Move secrets into a managed vault

Encrypt Sensitive Information (M1041) covers protecting secrets at rest and in transit, and a managed secrets vault is the practical way to apply it to T1552 exposure. Applications and pipelines retrieve credentials at runtime under a narrow identity instead of reading them from plaintext files. Confirm that the vault you choose supports encryption at rest, access policies per secret, and audit logging of reads, and that migration of legacy plaintext secrets is planned and tracked to completion.

Limit who can read each secret

User Account Management (M1018) reduces the number of identities that can reach a secret in the first place. Review group membership and service account permissions, remove standing access that is no longer needed, and separate human administrators from automation identities. Rotate credentials that were broadly readable before the change. Check that privileged access reviews cover vault policies and repository or CI secret scopes, not only directory groups.

Watch for secrets in code and pipelines

Repositories, container build contexts and CI logs are common places where credentials end up in clear text. Pair the vault approach with pre-commit and repository scanning that flags high-confidence secret patterns, and restrict who can view pipeline logs and build artifacts. Treat any detected secret as exposed: rotate it, review access logs for the period it was readable, and then remove it from history. Confirm how your scanning tool handles false positives and who owns triage.

Responding when a T1552 alert fires

The first job when a T1552 alert fires is to establish whether a credential was actually exposed and who it belongs to, before anyone changes anything. Confirm the exposed secret by reviewing the file, repository, container image, environment variable, or cloud metadata location that the alert references, and record its type (for example, an API key, a service account password, a cloud access key, or a private key). Then identify the owner and scope: which application, pipeline, or human account the secret authenticates as, and which systems, tenants, or data sets it can reach. The owning application team and the cloud or identity platform administrators should be pulled in at this stage, because they know the intended consumers of the secret and can tell you quickly whether a given authentication event is legitimate. Ask them to confirm the expected usage pattern, not just to agree that the alert is noisy.

Next, determine whether the secret was only readable or was actually used. Exposure and use are different risks, and the answer drives urgency. Review authentication logs for the account or key over the period since the secret was last known to be private, paying attention to source addresses, user agents, unusual times, and first-seen resources. Correlate with File Access telemetry from the host or repository platform to see which processes or users opened the file. Rotate or revoke the credential once the owner confirms it is compromised or cannot be confirmed as safe, and sequence the change with the application team so that the consuming service is updated from a secrets store rather than the same plaintext location. Check related access logs for the same identity in adjacent systems, and document each step with timestamps in a single incident timeline.

Preserve evidence before cleanup removes it. Collect the affected file, relevant log extracts, and host artifacts with a forensic collection tool such as Velociraptor, using a hunt or collection scoped to the hosts and paths in the alert, and record hashes and collection times. Confirm with your retention owner how long authentication and file audit logs are kept, since rotation and cleanup can overwrite the context you need. Finally, plan the follow-up: decide whether the plaintext location must be removed from version history, which dependent pipelines need updated secret references, and what the owning team will change so the same exposure does not recur. Confirm these decisions with your incident response and compliance leads, and agree the closure criteria in writing before the incident is marked resolved.

Rehearsing T1552 detection and response in a private cyber range

A private cyber range for T1552 should mirror the environments where unsecured credentials actually sit in your estate: Windows endpoints and file shares, Linux hosts with configuration and history files, a cloud or SaaS test tenant, and the SIEM and collectors that receive their telemetry. The range should be isolated from production networks and use synthetic accounts, secrets and data only. Confirm with your range provider which log sources, agents and retention settings are available before scenarios are drafted.

Windows and Linux hosts: Include endpoints with an agent forwarding Process Creation and File Access telemetry, so that searches of user profiles and configuration paths can be observed.
Cloud or SaaS test tenant: Provide an isolated tenant with authentication and audit logs enabled, populated with placeholder secrets only.
SIEM and collectors: Deploy the open-source SIEM, such as Wazuh, with rules that map to the agreed detection content, and confirm that event timestamps are synchronized across all sources.
Collector health checks: Verify before the exercise that every log source is delivering events, since a silent collector looks identical to a missed detection.
Versioned scope: Record the ATT&CK version the detection content targets, so results can be compared after later releases.

Before the exercise, check that each planned log source produces a test event on every range host.

Questions SOC leads ask about T1552 detection

How do I separate benign secret reads from attacker activity?

Start by baselining who should read secret stores, configuration files and credential material, and from which hosts, service accounts and pipelines. Benign reads are usually predictable: an application service account reading its own vault path, a deployment job reading a build variable at a known time. Attacker activity tends to break those patterns: a user or service identity touching secrets it has never accessed, bulk enumeration of many paths in a short window, reads from an unusual host, or access followed by outbound connections from the same process. Enrich each File Access or User Account Authentication event with the identity's normal behavior before alerting. Illustrative example: a CI runner that reads one secret per deployment is routine, while the same runner listing an entire secrets directory at 03:00 warrants investigation. Expect to tune for several weeks, and confirm that your secret manager emits read events with the requesting identity attached.

Which telemetry is usually missing on most estates?

Most estates collect endpoint process events but lack reliable file access auditing on the locations where secrets live. The common gaps are:

Object access auditing is disabled on configuration directories, home directories and shared drives.
Secret managers and cloud key services log only administrative changes, not read operations.
Repository hosting and CI platforms keep audit logs for a short retention window or not at all.
Linux hosts lack audit rules for reads of dotfiles, shell history and container runtime configuration.
Application log content is written without the requesting identity or correlation ID.

Before writing any rule, check each source against the ATT&CK data components relevant to T1552, such as File Access and User Account Authentication. Confirm with your platform team what is logged, at what verbosity, and for how long. A detection cannot fire on events you never recorded, so this inventory is often the most valuable first output of the project.

How should we handle secrets in repositories and CI logs?

Treat exposure in repositories and CI output as an incident with two parallel tracks: remove the access path and rotate the credential. Rotation matters more than deletion, because a secret pushed to a repository history or a log archive should be treated as compromised. Run secret scanning on commits, pull requests and build logs, and alert when a pattern matches a known credential format. Restrict who can read build logs, mask variables in CI output, and set retention limits you can defend in an audit. Detection work should include reviewing repository audit events for clones, forks and visibility changes after a leak is found. Ask your repository and CI vendors which audit events they export and whether they can stream them to your SIEM, since capabilities differ by product and plan.

How do we validate detections without affecting production?

Validate in a private cyber range or a staging tenant that mirrors the logging configuration of production, not in production itself. Build synthetic secrets that look like real credentials to scanners but grant no access, place them in the same kinds of locations, and run scripted reads from representative service identities. Record each step, then check whether the expected event reached the SIEM, matched the rule, and generated the right alert with enough context for triage. Measure the gap between the event time and alert time, and test what happens when a log source is delayed or dropped. Do not run this work against live secret stores unless your change process explicitly approves it, and keep a rollback path for any audit rule that increases log volume. Document each test against the ATT&CK version you target.

How do we map detections to ATT&CK 20.0 sub-techniques?

Map each detection to the specific sub-technique it covers, not just to T1552, because the sub-techniques describe different sources such as files, container and cloud credentials, and repository content. Pull the current technique and sub-technique list from the enterprise-attack 20.0 STIX bundle published in the attack-stix-data repository, and record the version you target in every rule. Then trace each rule to its detection strategy and analytic, and to the data components it depends on. Gaps usually appear where a sub-technique has no matching log source. Confirm the mapping against the current ATT&CK updates before each review cycle, because releases can rename, deprecate or revoke techniques. A simple coverage matrix with a column for the target version prevents silent drift.

How often should we retest T1552 detections?

Retest on a fixed schedule and after every change that affects logging, identity, secret storage or CI pipelines. A common pattern is a full test pass after each ATT&CK release that touches your mapped techniques, plus smaller regression checks after platform upgrades or new secret stores. Keep the test scripts in version control so results are repeatable and comparable. Your schedule should reflect how often your environment changes and how much an undetected exposure would cost you, so set the cadence with your risk owner rather than copying a figure from elsewhere. Ask any implementation partner to state in writing which tests recur, which are one-time, and what they will deliver as evidence for your assessors.

How DeployOpen builds T1552 detections and range scenarios

DeployOpen treats T1552 Unsecured credentials as a detection and response engineering task inside your own environment, not a generic checklist. Each engagement starts from a written scope that names the platforms, telemetry and ATT&CK version in use, then builds and tests detections that are documented for your team to run.

How we scope

Confirm which T1552 sub-techniques apply to your Windows, SaaS, IaaS and Linux estate before any build starts
Record the ATT&CK version each detection maps to, since releases can rename or deprecate techniques
Inventory which telemetry exists for Process Creation, File Access and User Account Authentication, and where gaps remain
Agree the written scope, deliverables and timeline in advance, as most engagements are fixed-scope

How we build

Write detection logic for T1552 in open-source tooling such as Wazuh, Sigma rules, Zeek or Suricata, as fits your stack
Map each rule to the ATT&CK data components referenced for Credential Access, starting with Process Creation and File Access
Test rules against benign administrative activity in a private cyber range to tune false positives before production
Document the mitigations mapped to T1552, including User Training and Audit, alongside the technical controls

How we hand over

Deliver detection documentation covering data sources, logic in plain words, known blind spots and tuning decisions
Provide range exercise runbooks so your analysts can rehearse detection and response on their own schedule
Hand over evidence packs that show which controls and detections were tested, prepared for your compliance assessors
Train responders on triage steps for each T1552 alert, with clear escalation paths to your incident team

How we support

Offer retainers for ongoing tuning, rule updates and retesting when ATT&CK versions or platforms change
Review detection coverage after platform upgrades, so T1552 rules keep matching the telemetry you collect
Confirm with DeployOpen during scoping which support levels and response windows are included in a retainer
Ask for a written quote that lists scope, deliverables and recurring support items before work begins

T1552 Unsecured credentials