How T1003 OS credential dumping shows up in intrusions
For a SOC lead, the moment an attacker reads credential material from a host is often the moment one foothold becomes wider access. T1003 OS credential dumping sits under Credential Access (TA0006), the tactic MITRE describes as the adversary trying to steal account names and passwords. Once an adversary can read secrets held by the operating system, every account those secrets unlock becomes a candidate for lateral movement, so detection on this technique protects the steps that follow it as much as the step itself.
At a high level, T1003 covers reading credential stores held by the operating system on Linux, macOS and Windows. It has 8 sub-techniques, each describing a different store or access path, and this page maps detection to ATT&CK version 20.0. ATT&CK releases can rename, deprecate or revoke techniques and sub-techniques (MITRE's ATT&CK updates page lists the changes by release), so every detection rule, coverage claim and audit artifact should name the version it targets. Before relying on this page, confirm the sub-technique list against the version your SIEM content and detection library reference.
The decision to make early is which hosts and which stores justify the most telemetry. Start with identity-bearing servers, domain controllers, jump hosts and administrative workstations, then confirm whether your current sensors report the data components this technique depends on, principally Process Creation, File Access and Process Access. Ask your team to record, for each sub-technique, which of these sources it can see today and which it cannot, because gaps in that inventory decide how much of the technique can be detected before any rule is written.
Which telemetry reveals credential dumping on each platform
This table maps the data components that ATT&CK uses for credential access detection (Process Creation, File Access, Process Access and User Account Authentication) to Linux, macOS and Windows. Read each row as the signal to look for, the open-source collector that brings it into your monitoring, and what to confirm before relying on it. Field availability depends on audit policy and logging configuration in your own environment, so validate each row before treating it as coverage.
| Data component | Linux | macOS | Windows |
|---|---|---|---|
| Process Creation (DC0032) | Execution of memory-reading or credential-store tools, or shells spawned by unexpected parents, captured by auditd or Wazuh log collection. Confirm that execve auditing is enabled. | Process start events from the unified logging or endpoint security framework, forwarded to Wazuh or a SIEM. Confirm which events your endpoint agent exposes. | Sysmon-style Event ID 1 process creation records, forwarded to Wazuh or Security Onion. Confirm that command line capture is enabled. |
| File Access (DC0055) | Reads of shadow, keyring or browser profile paths by non-standard processes, collected with auditd rules and Wazuh file integrity monitoring. Confirm watch rules exist for these paths. | Access to keychain files and browser credential stores, observed through endpoint file auditing and forwarded to Wazuh. Confirm that file access auditing covers user library paths. | Access to LSASS-related memory or credential store files, captured by Windows object access auditing and Sysmon-style logging. Confirm SACL configuration on sensitive objects. |
| Process Access (DC0035) | Ptrace-style access between unrelated processes, collected through auditd syscall rules where the kernel and policy support them. Confirm kernel audit coverage in your build. | Cross-process access to sensitive processes, available only where the endpoint security framework exposes it to your agent. Confirm vendor or platform support before relying on it. | Handle requests against the LSASS process, recorded as Sysmon-style process access events and forwarded to Wazuh. Confirm that the event filter targets LSASS and the relevant access masks. |
| User Account Authentication (DC0002) | Logins and sudo use that follow an unexpected credential read, from PAM and authentication logs collected by Wazuh. Confirm that authentication logs are retained centrally. | Authentication and local account events shortly after a credential store access, from the system log forwarded to a central platform. Confirm log retention period. | Logon events (such as Event ID 4624 and 4625) correlated with recent credential access, collected by the Wazuh Windows agent or Security Onion. Confirm that logon auditing is enabled. |
| Hunting and triage | Velociraptor artifacts can sweep for unusual reads of credential files and for processes with unexpected parents across endpoints. | Velociraptor collection can inventory recent process starts and file access to credential stores on hosts of interest. | Velociraptor can query process and handle information on suspected hosts to confirm or rule out credential access during triage. |
Detection logic for credential dumping, tuned to reduce noise
The four detection ideas below share one principle: credential dumping is a read or access event against a store that ordinary workloads rarely touch. Each card names the telemetry, the Sigma logic in words, the baseline thresholds to tune, and the benign sources that will trigger it. Targets are ATT&CK Enterprise v20.0, so confirm mappings against that version before deploying.
Unexpected processes reading credential stores
Alert when a process outside an approved allowlist opens protected credential stores such as /etc/shadow on Linux or a macOS keychain database. The Sigma logic matches File Access events on those paths, excluding known system binaries and the identity agents you run. Baseline the normal readers for two to four weeks before enabling the rule. False positives come from backup agents, configuration management tools and endpoint security products that legitimately scan these files. Tune by allowlisting parent process and signed binary hash, not by path alone.
Process access to LSASS on Windows
Alert when a process requests read access to the Local Security Authority Subsystem Service memory on Windows endpoints. The Sigma rule keys on Process Access events targeting the LSASS image, filtered by granted access rights that indicate memory reads, and excludes Windows Defender and approved EDR agents. Expect hits from endpoint protection, some remote management tools and admin troubleshooting sessions. Confirm which access masks your EDR uses before you trust the filter, and log exceptions with a named owner and expiry date.
Access to security subsystem stores
Alert on Process Access or File Access touching authentication subsystem data beyond LSASS, such as the Security Account Manager hive or NTDS.dit on domain controllers. The logic counts access by any non-system process and treats a single read from an unexpected host as high priority. Backup software, domain controller maintenance and forensic tooling are the main benign sources, so maintain a dated list of approved backup jobs and correlate with change tickets. Confirm with your platform team that object access auditing is enabled on the relevant hosts, since the rule is silent otherwise.
Correlating access with authentication anomalies
A credential store read matters most when followed by new logons using the same account or from the same host. Correlate the File Access or Process Access alert with User Account Authentication events within a short window, flagging logons from unfamiliar sources, unusual hours, or accounts that were not active before. Use a time window you set from baseline data rather than a fixed default. Expect benign correlations after password rotations, new hire onboarding and service restarts, so review these against identity change logs before escalating.
Baselining and threshold tuning
Tuning starts with a documented baseline per host group: which processes legitimately touch credential stores, how often, and at what times. Set alert thresholds on counts per host per day and require repeated hits before paging, while keeping single events from high-value hosts as low-severity records. Review suppressions monthly, and record the ATT&CK version and rule version in each change. Ask your vendor or platform team to confirm which Sigma backend and log source fields your SIEM supports before you port the rules.
How to validate that the T1003 detection fires
This sequence proves, in a private cyber range, that each T1003 sub-technique in scope produces the telemetry and alerts the detection depends on, and it records where coverage falls short so the gaps can be closed and re-tested. It ends with evidence the detection owner can accept or reject.
Agree emulation scope with the owner
The detection owner, the SOC lead and the range operator agree in writing which T1003 sub-techniques are in scope, which Linux, macOS and Windows hosts are included, and which accounts and systems are off limits. Name the ATT&CK version the mapping targets, since releases can rename or deprecate techniques. The step is done when the signed scope lists the hosts, the sub-techniques and the stop conditions, and everyone knows who can halt the exercise.
Approve the emulation plan
Select an emulation plan that maps each in-scope sub-technique to a planned behavior and to the expected data components, such as Process Creation, File Access and Process Access. The security lead reviews the plan so every step is safe for the range and has a rollback path. Done means each in-scope sub-technique has an approved line in the plan, with the expected telemetry written beside it so the team knows what success looks like before anything runs.
Confirm telemetry reaches the platform
Before any emulation, confirm that endpoint logs for the in-scope hosts arrive in Wazuh or Security Onion with the expected event sources enabled. Check agent status, log timestamps and parsing for process creation, file access and process access events on each operating system. Done means a benign test event from every in-scope host is visible in the platform with its fields parsed, so a later miss cannot be blamed on a silent log source.
Run the scoped emulation
The range operator executes the approved steps one sub-technique at a time, recording start and end times in the exercise log. The detection owner observes without changing rules during the run. Done means each planned step has a timestamp, a host, an account context and a note on whether it completed as designed, so the results can be matched against the expected telemetry later.
Confirm the rule fires and record time to alert
For each step, check whether the mapped detection rule or analytic raised an alert in Wazuh or Security Onion, and note the time between the emulated action and the alert. Verify that the alert appears in the intended queue with the right severity. Done means a results table lists, for each sub-technique, whether an alert fired, the measured delay, and the queue where it landed.
Check fields and log the misses
Review each alert and its underlying events to confirm the fields the analyst needs are present, such as host, user, parent process, target object and timestamp. Record every miss separately: no telemetry, telemetry without the needed fields, a rule that did not match, or an alert that fired but was suppressed. Done means each gap has a category and an owner, which turns a vague 'it did not work' into an actionable fix.
Close gaps and re-test after tuning
Work through the gap list with the detection engineer, adjusting log collection, parsing, rule logic or suppression, and documenting each change with its reason. Then rerun only the affected steps under the same scope and compare results with the baseline. Done means the re-test shows which gaps closed, which remain, and whether tuning introduced noise on benign activity, so the owner can accept the residual risk in writing.
Archive evidence for the detection owner
Package the signed scope, the approved plan, the telemetry checks, the results table, the gap log and the re-test comparison into one exercise record. Store it where the SOC and compliance teams can retrieve it, and set a review point tied to the next ATT&CK version the team adopts. Done means the record lets an independent reviewer trace each claim about T1003 coverage back to a specific test and result.
How detection differs across Linux, macOS and Windows
On Linux, credential material usually sits in files readable by privileged accounts, and in process memory of services that handle authentication. Detection therefore depends on file access auditing for sensitive paths and on process access records for processes that hold secrets. Many Linux hosts run without these controls enabled by default, so coverage must be confirmed rather than assumed.
- Telemetry available: File access events from the Linux audit subsystem for account databases and key material, and process creation records from the same or an endpoint agent.
- Attacker-visible artifacts: Reads of account and shadow-style files by unexpected processes, and access to memory of authentication-related processes by tools that are not part of normal administration.
- Detection gaps to confirm: Whether auditing covers the specific paths used by your distributions, and whether container and virtual machine hosts forward their logs.
- Logging configuration to request: Audit rules for the account database paths, central forwarding to Wazuh or a comparable collector, and retention long enough to support investigation.
- Ownership: Confirm which team owns audit rule changes, since frequent rule updates can change log volume.
Ask the platform team to show a sample of audit events from a representative host before the detection is considered live.
On macOS, credential material is spread across the user keychain, system keychains and the processes that unlock them. Visibility depends heavily on whether endpoint telemetry captures process access and file access to keychain locations, and on whether the fleet is managed centrally. Laptops that leave the corporate network can create gaps unless their telemetry reaches the central store.
- Telemetry available: Process creation events from the endpoint agent, and file access events for keychain storage locations where the agent supports them.
- Attacker-visible artifacts: Unusual processes interacting with keychain files, and access to the memory of security-related processes by software outside the management baseline.
- Detection gaps to confirm: Whether the endpoint agent supports file access and process access events on the macOS versions in your fleet, and whether events are collected when a device is off the corporate network.
- Logging configuration to request: Agent policy that enables the relevant event classes, a forwarding path for offline devices, and a documented baseline of legitimate keychain access by managed applications.
- Ownership: Confirm who maintains the management baseline, since unmanaged personal devices often fall outside the detection.
Ask the vendor or platform team to confirm which macOS versions and event classes are supported before relying on the coverage.
On Windows, credential material commonly sits in the memory of the local security authority and in registry hives, so process access telemetry is central to detection. Windows offers rich event sources, but many of the relevant events are off by default or generate high volume, which makes the logging configuration the main design decision. Domain controllers and administrative workstations need the most attention.
- Telemetry available: Process creation events, process access events for the security authority process where auditing is enabled, and file access events for registry hive locations and directories holding sensitive material.
- Attacker-visible artifacts: Processes opening the memory of the local security authority from unexpected parents, and reads of hive files by tools outside administrative use.
- Detection gaps to confirm: Whether process access auditing is enabled on domain controllers and servers, and whether command line content is captured with process creation events.
- Logging configuration to request: Audit policy for process creation and object access, Sysmon or an equivalent endpoint collector with a filtered configuration for process access, and forwarding to a central SIEM such as Wazuh.
- Ownership: Confirm that domain controller audit settings are changed through the directory team's change process.
Ask the platform team to demonstrate, in a test environment, that the required events reach the central store before the detection is considered complete.
Preventive controls that reduce credential dumping exposure
ATT&CK maps T1003 OS Credential Dumping to a small set of preventive mitigations. None of them stops an attacker who already has administrative access on a host, so they work best together: they shrink the number of people and processes that can reach credential material, and they make the remaining access easier to prove during an assessment.
User training for privileged operators
User Training (M1017) addresses the people most likely to be tricked into running a credential dumping tool or to approve a suspicious elevation request. Training for administrators, help desk staff and build engineers should cover why running memory or credential extraction tools on production hosts is off limits outside approved change, and how to report unexpected requests. Confirm which roles receive the training, how often it recurs, and whether completion is recorded. Assessors will ask for the curriculum, attendance records and a sample of how reported incidents were handled.
Encrypting sensitive credential stores
Encrypt Sensitive Information (M1041) reduces the value of credential material that sits on disk, in backups or in configuration. Relevant items include password vault files, key stores, hypervisor and database secrets, and memory swap or hibernation files on endpoints. Confirm which stores are encrypted at rest, where the decryption keys live, and whether those keys are separated from the data they protect. Ask for the key inventory and the encryption configuration as evidence.
Auditing privileged access to credential data
Audit (M1047) is the companion control that makes credential dumping visible when prevention fails. The question for each host class is whether the platform records process access to credential stores, changes to security-relevant settings and use of debugging privileges. Confirm the audit policy is enabled on the systems that matter, that logs are forwarded to a store administrators cannot silently edit, and that alerts are tied to a named response owner. Assessors typically request the audit policy export and a sample alert with its ticket.
Limiting who holds administrative rights
User Account Management (M1018) cuts the number of accounts that can read credential material in the first place. Review which accounts hold local administrator, root, domain administrator or equivalent rights, remove standing privilege where a time-bound or approval-based model is workable, and disable or rename default accounts where policy allows. Ask for the privileged account inventory, the review cadence and the record of the most recent review. This control is only as good as the list it is checked against.
Evidence assessors expect
Controls only count when they can be shown. For T1003, build a single evidence folder that maps each mitigation to an owner, a configuration artifact and a recent operating record, such as a training completion report, an encryption setting export, an audit policy export and a privileged account review. Confirm with your assessor which format they accept and how often evidence must be refreshed. DeployOpen can prepare this package as part of a fixed-scope readiness engagement, but independent auditors decide whether the controls are sufficient.
Triage and response when a T1003 alert fires
The first decision on a T1003 alert is whether it reflects expected activity or a possible credential theft, and that call should be made within the triage window your incident runbook defines. Confirm the alert against the raw telemetry from File Access, Process Creation and Process Access before anything else, because a single rule hit on a backup agent, an EDR sensor or an administrator's memory-analysis session can look identical to hostile access. Record the host, the account that performed the action, the parent process chain and the time window. Then check the change record, the on-call roster and any authorized maintenance for that host. If no expected activity explains the access, treat the alert as a probable incident and open a case. Confirm the exact rule and analytic version you are running, since ATT&CK releases can change detection mappings, and confirm the data source coverage on the host before drawing conclusions from silence.
Once the alert is confirmed, pull endpoint context from Velociraptor or your EDR platform: the process tree, loaded modules, network connections, scheduled tasks and recent logons on the affected host. Review the account's authentication history in User Account Authentication data across the directory and VPN, looking for logons from unfamiliar hosts, new source addresses or access to systems the account does not normally use. Scope other hosts by searching for the same process hashes, command patterns and account names across your fleet, and treat any host where the affected account has recent sessions as in scope until cleared. Decide on containment by weighing the account's privilege level against the business cost of isolation. For a domain or privileged account, plan to disable the account, revoke active sessions and rotate its credentials in a sequence that does not lock out legitimate services. Preserve evidence before reimaging: capture memory, export the relevant logs with hashes and chain-of-custody notes, and keep the Velociraptor collection output unchanged.
Rehearsing T1003 detection in a private cyber range
The range should mirror the operating systems your organization actually runs, so that the telemetry you test is the telemetry you will receive in production. For T1003, that means Linux, macOS and Windows endpoints with the same logging configuration, agents and collection paths as the production estate. The range must be isolated from production networks and from the internet, with its own identity sources and test accounts, so that no exercise traffic can reach a live system. Ask the team to document which hosts, agents and log sources are in the range and which differ from production.
- Client OS mix: Build a range host for each OS family and version in the production estate that is in scope, including any legacy builds that still handle credentials.
- Telemetry parity: Confirm that process creation, file access and process access events are collected on range hosts with the same audit settings and forwarding path as production.
- Network isolation: Enforce egress controls so the range cannot reach production systems or external services, and record the isolation checks as evidence.
- Identity setup: Provision disposable accounts and test secrets, never reused production credentials, and keep them in a separate directory or realm.
- Baseline capture: Snapshot each host and the Wazuh or SIEM configuration before the exercise so results can be compared against a known state.
Before scheduling any run, confirm with your platform team which log sources are present in the range and which are missing, because gaps there will hide gaps in production.
A scripted purple team scenario sets out, in advance and in writing, the ATT&CK techniques in scope, the sub-techniques to exercise and the expected telemetry for each step. The red side executes only the agreed steps in the range, and the blue side does not receive the script in advance. Injects are controlled events that test a specific part of the response chain, such as an alert that should fire, a ticket that should be routed, or an escalation that should reach an on-call owner. Scope must name the target versions of ATT&CK, since detection mappings change between releases.
- Written scenario: Agree the technique list, the sub-technique coverage, the timing rules and the stop conditions before the exercise, and sign off on them.
- Expected telemetry per step: For each step, record which data components should produce evidence, such as Process Creation, File Access or Process Access, and which rule should fire.
- Alerting injects: Introduce a benign event that matches a detection, then check whether it reaches the analyst queue with the expected severity and context.
- Escalation injects: Simulate a confirmed credential access event and measure whether the handoff reaches the incident commander and the owner of the affected platform.
- Stop and rollback rules: Define how the exercise halts if a production system is touched, and how range hosts are reset afterward.
Illustrative example: a scripted step could target a credential store on a Linux range host, with the expected file access and process access events listed in the scenario document before the run begins.
Judge the exercise against criteria agreed before the run, not against impressions afterward. Alert quality matters as much as alert volume: a rule that fires on every access to a credential file trains analysts to ignore it. Handoff timing shows whether the people who must act can do so, and whether the escalation path works outside business hours. Record each finding with the evidence that supports it, then assign owners and retest the fixes in a later run.
- Alert quality: Check that each expected alert fired, carried the host, user and process context an analyst needs, and was not flooded with duplicates from unrelated activity.
- Coverage gaps: List each scripted step that produced no alert, and identify whether the cause is a missing log source, an audit setting, or a rule gap.
- Handoff timing: Measure the time from alert to analyst acknowledgment, and from analyst triage to escalation, using timestamps from the ticketing and paging tools.
- Response actions: Confirm the containment steps were executed as written, such as resetting the test secret and isolating the range host, and that the evidence was preserved.
- Lessons and retest: Document each finding with an owner and a retest date, and rerun the affected injects to confirm the fix.
Before accepting results, ask the team to show the raw events behind each alert, so the findings reflect what the sensors actually saw.
Questions SOC leads ask about detecting T1003
How do I scope T1003 across its eight sub-techniques without boiling the ocean?
Start with the platforms you actually run, then map each sub-technique to the platform where it applies and to the telemetry you already collect. T1003 spans OS credential dumping on Linux, macOS and Windows, so a single rule set rarely fits all three. Write the scope as a table: sub-technique, platform, data component, log source, owner and the ATT&CK version you mapped against. Rank rows by business exposure, such as domain controller and privileged workstation coverage first. Confirm the sub-technique list against the ATT&CK 20.0 STIX bundle in your own tooling rather than relying on memory, because sub-technique names and counts change between releases. Review the scope table at each ATT&CK update.
How do I handle noisy endpoint security tools that flag credential access activity?
Treat the endpoint security alerts as one signal source, not as the detection itself. Many endpoint products already alert on credential access behavior, which produces volume from legitimate administration, backup agents and security tooling itself. Build an allowlist from known-good processes and accounts, but document each exclusion with an owner, a reason and a review date so exclusions do not quietly become blind spots. Forward the endpoint alerts into your SIEM, correlate them with File Access, Process Creation and Process Access events, and prioritize combinations rather than single events. Confirm with your endpoint vendor which telemetry it exposes and how its exclusions are logged.
Is Sysmon-style process logging required to detect T1003?
No single product is required, but you need equivalent visibility into process creation and process access on Windows, and comparable file access and process events on Linux and macOS. Sysmon is a common choice on Windows because it records process creation and process access with configurable filters. On Linux, auditd or an equivalent kernel audit source can supply file and process events, and on macOS you should confirm which unified logging and endpoint sources your platform exposes. Whatever you choose, verify that the events carry the fields your rules need, that the configuration is version controlled, and that logs reach Wazuh, Security Onion or your SIEM without gaps.
How do I map detections to ATT&CK 20.0 and handle version changes?
Name the ATT&CK version in every detection record, and map against the enterprise-attack 20.0 STIX bundle published in the attack-stix-data repository. ATT&CK publishes one bundle per domain and version, so your mapping can be checked by script rather than by hand. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and later releases can rename, deprecate or revoke techniques. Store the mapping in version control, diff it against each new bundle, and retire rules whose technique IDs change. The ATT&CK updates page is the natural place to check what changed before you re-baseline.
How do I test T1003 detections without affecting production?
Rehearse in a private cyber range or staging environment that mirrors your production logging pipeline, with the same agents, log formats and SIEM rules. Use test accounts, isolated hosts and a written change window, and agree the scope and rules of engagement before anyone runs an exercise. Confirm that test activity cannot reach production credentials or domain controllers, and that every exercise has a named owner who can stop it. Record the exact ATT&CK sub-technique, the telemetry produced and whether each alert fired, so results can be replayed after tuning. DeployOpen runs private cyber ranges and security testing as fixed-scope engagements, with scope and deliverables agreed in writing before work starts.
How do I measure whether my T1003 detection actually works?
Measure coverage, fidelity and response, not just the number of rules. Coverage asks which sub-techniques and platforms have a validated detection with a known data source. Fidelity asks how often a detection fires on a test exercise and how often it fires on benign activity over a fixed period. Response asks how long it takes an analyst to triage, escalate and contain, and whether the playbook was followed. Track these per ATT&CK version and review them after each cyber range exercise. Keep the raw results as evidence, and confirm with your auditor which artifacts they expect before you decide the format.
How DeployOpen builds T1003 detections and range exercises
DeployOpen starts every T1003 OS credential dumping engagement with a written scope that names the platforms in play (Linux, macOS and Windows), the telemetry the client can actually provide, the ATT&CK version the detections will target, and the decisions the client must own. Because ATT&CK can rename, deprecate or revoke techniques between releases, the scope should record the exact version, for example the Enterprise ATT&CK 20.0 bundle, so that every Sigma rule maps to a stated technique or sub-technique ID. Before any rule is written, the team inventories which of the data components tied to T1003, such as Process Creation, File Access and Process Access, are collected today, at what fidelity, and on which hosts. Gaps found at this stage are usually cheaper to close than to work around later.
Detection work is then built or tuned against the client's own telemetry rather than delivered as a generic rule pack. DeployOpen's engineers write or adapt Sigma rules, convert them for the client's Wazuh, Security Onion or Velociraptor pipeline, and measure how each rule behaves on a baseline of normal administrative activity, since tools that legitimately read process memory or registry hives on domain controllers and servers are a common source of noise. Purple team exercises are planned under written rules of engagement that fix the test window, the systems in scope, who on the defensive side is informed, how the exercise is stopped, and how findings are handled. The same private cyber range can reproduce the client's configuration so that the rehearsal reflects their environment. Each range scenario ends with documented evidence: the scenario record, which rules fired or failed, timestamps, tuning changes, and open gaps with owners. DeployOpen prepares this evidence for the client's own assessment team, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Engagements are fixed-scope, and a quote follows from the written scope, so the client should ask for the deliverables, the number of platforms, the range environment and the retesting cycle to be stated before work starts.
