Why T1555 credentials from password stores matters to SOC teams
A SOC lead needs a clear answer to one question: are unexpected processes reading the secrets stored in browsers, password managers, keychains and vaults? This page explains how to detect that activity with open-source tooling, mapped to MITRE ATT&CK technique T1555, Credentials from password stores. In ATT&CK, the Credential Access tactic (TA0006) describes adversaries trying to steal account names and passwords. T1555 sits under that tactic and has 6 sub-techniques, which cover password stores on IaaS, Linux, macOS and Windows. Because each platform stores secrets differently, detection logic has to be written for each one and tested before it is reused across the estate.
Stored secrets are attractive because one successful read can expose many accounts at once. A browser profile, a keychain entry or an exported vault may hold service passwords, session material or API keys that were never meant to leave their store. The decisions that follow are practical. Confirm which password stores exist in your environment, including developer workstations, build hosts and cloud secret managers. Decide which telemetry you will collect for File Access, Process Creation and Process Access, since these are the data components ATT&CK most often references for Credential Access. Then check which of the six sub-techniques apply to each platform you run, and record that mapping before writing any detection.
Every mapping should name the ATT&CK version it targets. This page targets Enterprise ATT&CK v20.0, and that choice matters because MITRE can rename, deprecate or revoke techniques between releases, which would quietly break a detection that cites an outdated ID. Ask your detection engineering team to store the version alongside each Sigma rule or Wazuh rule, and to re-check mappings whenever a new release arrives. The ATT&CK updates page lists release notes, so you can review changes before you upgrade your rule set.
Which data sources reveal T1555 and which open-source tool collects them
This table maps the data components most relevant to T1555 to the signal worth watching, the open-source collector that gathers it, and whether the signal depends on OS audit policy. Read each row as a question to confirm in your own environment before you rely on it for alerting.
| Data component | Signal to look for | Open-source collector | Depends on audit policy |
|---|---|---|---|
| File Access (DC0055) | Reads of browser credential stores, password manager vaults, or keychain files by processes that are not the owning application | Wazuh agent file integrity and audit rules, or Velociraptor artifacts on endpoints | Yes |
| Process Creation (DC0032) | Command lines or parent-child chains that invoke credential store utilities or scripts that enumerate vault contents | Sysmon-style process telemetry collected through Wazuh or Velociraptor | Yes |
| Process Access (DC0035) | Handles opened against credential manager or LSA-related processes by unexpected binaries | Sysmon-style process access events forwarded to Wazuh, or Velociraptor hunts | Yes |
| User Account Authentication (DC0002) | Unlock or access events for vaults, keychains or cloud secret stores followed by unusual logons from the same account | Wazuh decoders for Windows and Linux authentication logs, plus cloud identity sign-in logs | No |
| Application Log Content (DC0038) | Access logs from secret managers, vault services or password tools showing bulk reads or reads from new source addresses | Wazuh log collection from application or vault logs, or Security Onion ingesting application logs | Yes |
| Network Traffic Content (DC0085) | Outbound transfers of files or archives from hosts that recently read credential stores, as context for other signals | Zeek and Suricata sensors in Security Onion, used for context rather than primary detection | No |
| Cloud audit logs (IaaS secret stores) | Get or list calls against secret, key or parameter stores from unexpected principals, IP ranges or times | Cloud-native audit trails forwarded to Wazuh or a SIEM pipeline, confirmed with the provider's documentation | No |
Detection ideas for password store access, described in words
The four ideas below watch the same moment from different angles: a process reaching into a place where saved secrets live. Each one pairs a telemetry source with a baseline, because most noise in this area comes from legitimate software that is supposed to touch these stores. Tune each idea against your own fleet before treating any alert as a finding.
Non-browser access to browser credential stores
Browser credential databases and operating system keychain files are the most common targets under T1555. Use File Access telemetry to flag reads of these stores by processes that are neither the owning browser nor a known profile sync or migration tool. Set the threshold on distinct unexpected processes per host per day rather than on single events, and build a baseline of which applications legitimately read these files during the first weeks of collection. Expected false positives include password manager browser extensions, enterprise browser management agents and backup software that copies user profiles. Confirm each exclusion by hash and signer, not by name alone.
Process access to vault processes
Password managers, credential vaults and secret brokers keep decrypted material in memory while running. Process Access telemetry shows when a process opens a handle to one of these processes with rights that allow memory reads. Alert when the accessing process is not a registered debugger, endpoint security agent or known vendor component, and track the access rights requested as well as the caller. Expect false positives from endpoint protection products, crash reporters and vendor update services that inspect vault processes during upgrades. Validate the baseline across a maintenance window so these routine accesses are documented before tuning.
Enumeration of secret stores on IaaS
On cloud instances, secrets often sit in local configuration files, instance metadata helpers and credential caches. Process Creation and File Access telemetry can show a single session touching many of these locations in a short window, which is the pattern that matters more than any one read. Set a threshold on the number of distinct secret locations accessed per session within a fixed interval, and separate interactive administrator sessions from automation accounts. Configuration management, container runtimes and deployment agents produce heavy legitimate enumeration, so map them to their service accounts before alerting.
Access from unexpected parent processes
A process that reads a password store is often less suspicious than the chain that launched it. Process Creation telemetry lets you compare the parent of each access-related process against an allowlist of expected parents, such as a browser, a vault client or a known management agent. Flag cases where a script interpreter, a remote management shell or an office application is the ancestor of a process that later touches a secret store. Baseline the parent chains for each role in your fleet, and expect false positives from software updaters and scheduled maintenance tasks that spawn helpers from unusual parents.
How T1555 detection differs across Windows, macOS, Linux and IaaS
On Windows, T1555 activity centers on the Credential Manager vault and on browser password stores that sit inside the user profile. Reads of the vault go through platform interfaces that may not produce a file event, so the strongest evidence often comes from process behavior on the host. Browser profile databases give file-level evidence, but only when object access auditing covers those paths.
- Telemetry gap: Vault reads may leave no file event, so Process Creation and Process Access carry more weight than File Access for this platform.
- Signal priority: Start with Process Creation for unexpected binaries that touch vault or profile locations, then Process Access against credential-handling processes, then File Access on browser profile databases.
- Browser stores: Profile databases are typically locked while the browser runs, so copy attempts by a process outside the browser are a useful indicator. Test this against normal backup and sync tools in your fleet.
- Auditing prerequisites: Object access auditing and command line logging are settings you enable deliberately. Confirm the audit policy and any GPO baseline with Microsoft documentation and your endpoint team.
- Agent coverage: Sysmon or an EDR agent may expose handle-level telemetry only on certain Windows builds. Confirm which builds and event types your agent records.
Confirm with your endpoint team which Windows builds and agents expose the events above before writing any rule that depends on them.
On macOS, credential access centers on the user keychain, which applications reach through system security interfaces. Keychain reads are mediated by the operating system, so the visible signals are often access prompts, unusual process lineage and file access to the keychain database rather than a single clean file event. Detection quality depends heavily on which endpoint security events your agent receives.
- Telemetry gap: Keychain access through system APIs may generate no file event for the reading process, so process-level telemetry is the primary source.
- Signal priority: Start with Process Creation for unsigned or unexpected binaries invoking security tooling, then File Access on the login keychain database, then Process Access where the agent provides it.
- Authorization prompts: A keychain access prompt raised from an unexpected parent process is a strong contextual signal. Unified logging can record these events, but retention varies by configuration, so confirm how long your logs are kept.
- Agent permissions: Endpoint agents may need elevated permissions to receive the events you need. Confirm the permissions your agent requires and how they are granted in managed fleets.
- Version coverage: Event availability changes across macOS releases. Ask the agent vendor which macOS versions and event types are supported before you rely on them.
Check with your endpoint vendor which macOS versions and event types are supported, and document the answer alongside each detection.
On Linux, credentials sit in two broad places: desktop keyrings reached through the Secret Service interface over the session bus, and plain files such as SSH keys, cloud CLI configuration, netrc files and database client files. File-based stores are easier to watch than keyrings, but developers and automation read them constantly, so baselines matter more than the watch itself.
- Telemetry gap: Keyring access over the session bus may produce no file event, so process lineage and bus-level activity, where available, are the main evidence.
- Signal priority: Start with File Access on known credential files read by processes that do not normally touch them, then Process Creation for tools that query keyrings, then User Account Authentication for logins that precede the reads.
- File integrity and audit: File integrity monitoring and audit subsystem rules can cover credential paths. Tune them by user, process and parent process to limit noise from legitimate tooling.
- Baselines: Build allow lists per role, such as developer workstations and CI runners, and review them after each fleet change.
- Distribution differences: Audit subsystem versions, default rules and log formats differ across distributions. Confirm what your fleet logs before writing rules.
Confirm with your platform team which distributions, audit configuration and log retention apply to each host group before you deploy file-based rules.
In IaaS environments, T1555 covers secret manager retrieval through provider APIs and credentials exposed through the instance metadata service on a workload. The control plane usually records secret retrieval, but requests to a local metadata endpoint may only appear in host or network telemetry. Detection therefore combines provider audit trails with workload-level evidence.
- Telemetry gap: Secret reads through the API appear in control-plane audit logs, while metadata requests may be visible only in host or network telemetry.
- Signal priority: Start with control-plane audit records for secret retrieval by identities that do not normally read those secrets, then User Account Authentication for unusual identities, then Application Log Content from workloads that request credentials.
- Data event settings: Read events for secrets may be disabled or limited by default in some providers. Confirm which data events are enabled, how long they are retained and what enabling them costs in your account.
- Metadata access: Where your platform allows, restrict metadata access to workloads that need it, and review requests from containers and sidecars that should not call it.
- Identity mapping: Map each secret to the identities allowed to read it, so that an unexpected read has a clear owner to review.
Ask your cloud provider for the exact audit event names, retention periods and data event options for your account, and confirm them in writing before you build alerts.
How to validate that the T1555 detection fires
This sequence proves that the T1555 detections raise the right alerts, at the right time, for the sub-techniques you actually cover. It ends with a tuned rule set and a record of each run that an auditor or peer can review.
Agree scope and rules of engagement
The security lead, the detection engineer and the platform owner agree in writing which systems, accounts and credential stores are in scope, which sub-techniques are covered, and when emulation may run. Name who can stop the exercise and how it is escalated to the on-call team. Record the ATT&CK version the detections target, because releases can rename or revoke techniques. The step is done when the signed scope document exists and every in-scope host is listed in the lab inventory.
Select sub-technique coverage
Map each of the six T1555 sub-techniques to the platforms your estate runs, such as Linux, macOS, Windows and IaaS, and mark which ones have an active detection analytic. Prioritize the sub-techniques that touch credential stores present in your environment. Keep the matrix as a controlled document so later runs can be compared with earlier ones. The step is done when each covered sub-technique has a named owner, a target platform and a detection reference.
Build the isolated lab environment
Stand up the lab in a private cyber range that mirrors the production logging configuration, including the same audit policies, agents and retention settings. Confirm that the lab cannot route to production networks or to shared credential vaults. Snapshot each test host before a run so the state can be restored and compared. The step is done when a connectivity check shows the lab is isolated and the baseline snapshots are recorded with their timestamps.
Run the emulation for each sub-technique
The red team or the designated test operator runs the agreed emulation for one sub-technique at a time, using a documented procedure approved in the scope step. Each run has a unique identifier and a start and end time written in the run log. The detection engineer does not see the operator's notes until the run closes, which keeps the result honest. The step is done when every planned run has a completed entry, including runs that produced no alert.
Confirm telemetry reaches the SIEM
Before judging the detection, check that the required data sources arrived in the SIEM, including Process Creation, File Access and Process Access events where the platform emits them. Compare the event timestamps with the run log to find ingestion delay and dropped fields. If telemetry is missing, log the gap as a collection defect rather than a detection failure. The step is done when each run has a telemetry status of complete, partial or missing, with the reason noted.
Record alert timing and fidelity
For each run, record whether the expected alert fired, how long after the activity it appeared, and whether it carried the host, user and process context an analyst needs. Score fidelity as a simple label such as high, medium or low, agreed in advance. Note any alert that fired for a different reason than the emulated behavior. The step is done when every run has an alert outcome, a delay value taken from the timestamps and a fidelity label.
Tune for false positives in the lab
Replay ordinary administrative activity from the same hosts, such as password manager updates, browser profile reads and backup agents, and count how many alerts they produce. Adjust the analytic conditions or exclusions only where the cause is understood, and record each change with its reason. Re-run the emulation after tuning to confirm the true detections still fire. The step is done when the benign replay produces an agreed, documented alert count and the post-tuning re-run matches the pre-tuning results for true activity.
Retain the run record for review
Store the scope document, sub-technique matrix, run logs, telemetry status, alert outcomes and tuning changes together, tagged with the ATT&CK version and the detection version. Give the compliance lead and the control owners read access so the evidence can be matched to the Credential Access controls they maintain. Schedule the sequence again when detections or ATT&CK versions change. The step is done when the record can be reproduced from the stored artifacts without asking the original operator.
Preventive controls that reduce T1555 exposure
T1555 succeeds when credentials sit in password stores that are readable by the wrong process or user. The controls below reduce how much is stored, who can read it, and how quickly weak or exposed secrets are found. Confirm each mapping against the ATT&CK version your team targets, because mitigation mappings can change between releases.
Password policy and vault hygiene
Password Policies (M1027) is the ATT&CK mitigation most directly tied to T1555 exposure. For browser stores, password managers and keychains, the practical question is whether master passwords, unlock timeouts and screen-lock rules are enforced on managed endpoints. Check that corporate policy covers local vaults as well as directory accounts, and that reused or weak credentials are flagged for rotation. Policy text alone does not stop an unlocked vault from being read.
Software update discipline
Credential stores are often read through flaws in browsers, password managers, operating systems and credential-handling services. Update Software is the control that closes those flaws. Build an inventory of endpoint applications that hold credentials, set a patch cadence for each, and track exceptions with owners. Ask your vendors which versions fix known credential-store issues, and confirm that patch status feeds into your asset records.
Least privilege for stored secrets
User Account Management (M1018) limits which accounts can read another user's stored secrets. Review local administrator membership, shared service accounts and privileged logons on workstations and servers that host credential stores. Remove standing rights that let one account open another user's keychain or profile data. Test the result with a non-privileged account to confirm access is actually blocked.
User training on secret storage
User Training (M1017) addresses the habit of saving credentials in browsers, spreadsheets, notes and plain-text files. Teach staff which storage tools are approved, why shared vault entries should not be copied into personal notes, and how to report a suspected exposure. Training works best when paired with an approved password manager, because people will otherwise choose the nearest place to save a secret. Measure completion and follow-up reports, not just attendance.
Encryption of stored credentials
Encrypt Sensitive Information (M1041) reduces the value of a copied store. Confirm that password databases, keychain files and application secret stores are encrypted at rest with keys tied to the user or a managed key service, and that exported backups carry the same protection. Identify any store that keeps credentials in plain text or with a recoverable key stored beside it, and make its migration a tracked item.
Mapping checks against your ATT&CK version
Mitigation and data component mappings change across ATT&CK releases, so record which version your detection and control catalog targets. Ask your team to confirm the current mitigation IDs for T1555 and its sub-techniques in the STIX bundle for that version before you cite them in audit evidence. This keeps the control set traceable when a technique is renamed, split or deprecated.
Triage and response when a T1555 alert fires
When a T1555 alert fires, the first task is to establish whether a credential store was read by a process that should not have touched it. Start by confirming the accessing process: its executable path, parent process, command context, signer and the user session it ran under. Then confirm the user account, the host and the time window, using the File Access and Process Access events that triggered the alert and widening the window to the minutes before and after. Record each finding with its timestamp so the timeline can be rebuilt later. Treat the alert as unconfirmed until these facts are in hand.
Next, test whether the access is explained by normal activity. Browsers, password managers, sync clients and operating system components read their own credential stores routinely, and a software update or profile migration can produce the same pattern. Check the change record, the endpoint management system and the software inventory for the host, and confirm with the application owner whether an update or sync ran in the window. If the process cannot be tied to a known, signed application and an approved change, escalate. Then scope other hosts: search the same process name, path, hash and parent pattern across the fleet over a comparable period, because a single host is rarely the only exposure.
Decide on containment and credential rotation early, because stored secrets are usable away from the host. For each affected account, list the browser-saved passwords, session tokens, SSH keys and cloud access keys that the host could have reached, and rotate the ones tied to privileged or shared accounts first. Ask your identity team to revoke active sessions where the platform supports it, and confirm with the vendor which of your credential stores are encrypted per user or per machine so you know what an attacker could decrypt. Preserve evidence before you reimage: take a forensic copy of the host, export the relevant Sysmon, EDR or operating system logs to write-once storage, and record the chain of custody. Do not rely on the endpoint to keep its own logs.
How to rehearse T1555 detection in a private cyber range
Start by building isolated test hosts that mirror the operating systems in your estate: Windows, Linux, macOS and at least one IaaS test instance. Each host should sit on a segment with no route to production identity stores, production secrets managers or internet egress that would expose test activity. Populate every host with dummy stored credentials, such as browser profiles, keyring entries, SSH agent entries and cloud CLI profiles that contain placeholder values only, so the exercise never touches real secrets. Enable the telemetry you intend to rely on, including file access auditing on credential store paths, process creation logging and process access logging where the platform supports it. Confirm with each vendor and your own platform team which audit settings are required for each credential store on each operating system, because defaults vary. Record the build as code so the range can be rebuilt identically for each exercise.
- Isolated hosts: Keep every test host on a segment with no route to production identity or secrets infrastructure.
- Placeholder secrets: Use fake account names and values that cannot authenticate anywhere.
- Telemetry baseline: Confirm that file access, process creation and process access events reach the SIEM before any inject runs.
- Versioned build: Store the build definition so each exercise starts from the same state.
- Log path check: Verify the collector on each host forwards events from the paths the detections depend on.
Before the first exercise, check that every host's telemetry arrives in your Wazuh or Security Onion stack with the fields your detection logic expects.
An inject is a scripted action performed by the red or purple team that resembles the T1555 behavior being tested, without using real secrets. Write each inject as a short, numbered scenario with a stated goal, the host it runs on, the ATT&CK sub-technique it targets and the telemetry it should produce. Keep the actions observable and reversible, and avoid anything that would extract or use a credential beyond the dummy values. Run injects in a fixed order, and log the start and end time of each one so alerts can be matched to actions afterward. Include at least one inject that touches the credential store and one that only reads an adjacent file, so you can see whether the detection distinguishes them. Describe the exact technique steps in your internal runbook only, not in shared documents, and have a qualified tester approve each inject before it runs.
- Scenario cards: Give each inject a goal, target host, sub-technique and expected telemetry.
- Timestamped log: Record when each action starts and ends so alerts can be correlated.
- Control injects: Include benign actions that should not alert, to measure false positives.
- Approval step: Require sign-off from the test lead before each inject runs.
- Reset between runs: Restore the dummy credential stores to their baseline state.
Check that every inject can be stopped quickly and that the range team knows how to abort it.
Detection quality has two measures: whether the alert fired in time, and whether it named the right account, host and process. Compare each inject's timestamped log with the alert timestamps in your SIEM, and record the delay between the action and the first alert that matches it. Check attribution by confirming that the alert identifies the correct user, host, process and file path, and that it does not blame an unrelated service account or a backup agent. Review the control injects to see whether benign activity triggered alerts, and tune the logic where it did. Map each result to the ATT&CK version your detections target, and note any sub-technique that produced no alert. Treat a missing event as a telemetry gap until proven otherwise. Confirm the expected alert latency and thresholds with your SIEM vendor and your own engineering team, because the acceptable delay depends on your monitoring design rather than on a universal figure.
- Timeliness: Measure the gap between each inject and its first matching alert.
- Attribution accuracy: Check that user, host, process and path fields are correct.
- False positives: Count alerts raised by the control injects.
- Coverage gaps: List each sub-technique that produced no alert and why.
- Version tag: Record the ATT&CK version and rule version used for each result.
Finish with a short findings list that assigns each gap to an owner and a retest date.
Response is judged by whether the on-call analyst followed the triage playbook and whether the credential exposure was contained. Give the analyst the alert without prior warning, and observe each step against the playbook: scoping the affected host, identifying which stored credentials were accessed, checking related sessions, and deciding whether to isolate the host. Test rotation as a real procedure against the dummy accounts, confirming that the owner can disable and reissue each credential and that dependent systems are identified before the change. Record where the playbook was unclear, where the analyst lacked access, and where a step took longer than the team expected. Confirm with your identity and secrets platform owners which rotation steps are supported for each store, because capabilities differ by product. Hold a short debrief after each exercise and update the playbook with the changes.
- Playbook adherence: Check each triage step against the written procedure.
- Scope accuracy: Confirm the analyst identified all affected hosts and credential stores.
- Rotation test: Disable and reissue a dummy credential, then confirm dependent test systems follow.
- Access check: Verify the analyst has the permissions the playbook assumes.
- Debrief record: Log playbook changes and assign owners.
Before closing the exercise, confirm the playbook reflects what the team actually did, not what it planned to do.
Questions detection engineers ask about T1555
How do I separate normal browser sync from credential theft on T1555?
Start by treating browser sync as a known, expected pattern and baseline it, rather than as an exception to ignore. Legitimate browser sync and profile synchronization read the same credential stores that theft targets, so a rule that alerts on any access to the browser login database will be noisy. Build the detection around the combination of signals: which process opened the store, its parent process and signing status, the user session, the host, and whether the access happened outside the browser's own update and sync windows. Confirm with your endpoint vendor which file access and process access events it records for these paths and whether it exposes the requesting process details you need. Validate the baseline in your own fleet before you tune thresholds.
How should I handle ATT&CK version changes between v18, v19 and v20?
Name the ATT&CK version in every detection mapping, because releases can rename, deprecate or revoke techniques and sub-techniques. MITRE's v18 release notes describe the move from detections in technique pages to detection strategies and analytics, plus major updates to data components and the deprecation of data sources. Recent releases include v19 in April 2026 and v20 in October 2026, so a mapping written against one version may point to changed identifiers in another. Pin your rule repository to a specific STIX bundle, record the version and date in each rule's metadata, and diff the bundles when you upgrade. Confirm with the ATT&CK updates pages which changes affect T1555 and its sub-techniques before you migrate.
Which data components should I prioritize for T1555 detection?
Prioritize File Access and Process Creation, then Process Access, because these are the data components most often referenced by ATT&CK detection strategies for Credential Access techniques and their sub-techniques in the enterprise-attack 20.0 bundle. File Access shows reads of password manager vaults, keychain files and browser credential stores. Process Creation adds context about what launched the access. Process Access helps where a tool reads protected stores through another process's memory or handles. Confirm with your collection stack that these events are actually generated on each platform, since coverage often differs between Windows, Linux and macOS, and between IaaS hosts and workstations.
How do I test the false positive rate of a T1555 detection?
Measure it against a labeled set of benign and malicious events, not against an impression of noise. Run the candidate rule for a representative period on production-like endpoints, record every alert, and classify each as expected software activity, administrative action, or unexplained. Then replay known attack behavior in a private cyber range so you can measure detection rate alongside false positives. Track alert volume per host and per user, because a rule that fires rarely on a few servers may still flood the queue when deployed fleet-wide. Document the test inputs, the ATT&CK version, and the tuning decisions so an assessor can reproduce the result.
Do IaaS secret manager logs cover T1555 for cloud-hosted secrets?
Secret manager audit logs cover access to the managed secret service, but they do not cover credential stores on the virtual machines or containers that consume those secrets. Cloud secret services typically record API calls such as retrieval or listing of secret values, which is useful evidence for the cloud control plane. They will not show a local process reading a browser store or keychain on a host. Confirm with your cloud provider which events are logged, whether data access logging must be enabled explicitly, the retention period, and whether logs can be exported to your SIEM. Then combine them with host telemetry from the instance itself.
Which ATT&CK mitigations support T1555 besides detection?
The mitigations ATT&CK most often maps to Credential Access techniques include Password Policies, User Account Management, User Training, Encrypt Sensitive Information, Audit and Active Directory Configuration. For T1555, the mapping most relevant to reducing exposure is Password Policies and Update Software, which the page covers in detail. Detection engineers should confirm with the current ATT&CK mapping for their version, because the mitigations attached to a technique can change between releases.
Can my team run T1555 detection and response rehearsals without external help?
Yes, a capable internal team can run these rehearsals, but the work is more than writing a rule. It requires an isolated range with representative endpoints, a plan for generating benign and simulated activity safely, a collection pipeline that matches production, and a repeatable way to score detections. DeployOpen runs private cyber ranges and security testing, and engagements are typically fixed-scope, with scope and deliverables agreed in writing before work starts. Ask any provider to confirm which vendor capabilities, log sources and platforms are in scope before you commit.
How DeployOpen builds T1555 detections and range scenarios
DeployOpen approaches T1555 Credentials from password stores as a fixed-scope engagement inside the client's own environment. The work covers the telemetry, detection logic and cyber range rehearsal needed to confirm that password store access is seen, triaged and handled.
How we scope
- Agree in writing which platforms, such as IaaS, Linux, macOS and Windows, are covered for T1555 detection.
- Confirm which of the six T1555 sub-techniques are in scope and which telemetry sources already exist.
- Record the ATT&CK version the detection mappings target so later releases can be compared cleanly.
How we build
- Map File Access, Process Creation and Process Access telemetry to detection logic described in plain language.
- Build open-source detections with Wazuh, Sigma rules and Security Onion or Zeek where the client's stack supports them.
- Document the mitigations Password Policies and Update Software and the controls that support them in the client's environment.
How we hand over
- Deliver written detection logic, data source requirements and tuning notes the client's own team can maintain.
- Run cyber range scenarios that replay T1555 behavior against the client's detections and record the results.
- Provide response runbooks and a validation report that names the gaps still open after the engagement.
How we support
- Offer ongoing support as a retainer for detection updates, tuning and retesting after ATT&CK releases.
- Re-run cyber range exercises when telemetry sources, logging configuration or platforms change.
- Confirm with the client which support scope, response times and review cadence apply before work starts.
