T1555.002: Securityd Memory
An adversary with root access may gather credentials by reading `securityd`’s memory. `securityd` is a service/daemon responsible for implementing security protocols such as encryption and authorization.[1] A privileged adversary may be able to scan through `securityd`'s memory to find the correct sequence of keys to decrypt the user’s logon keychain. This may provide the adversary with various plaintext passwords, such as those for users, WiFi, mail, browsers, certificates, secure notes, etc.[2][3]
In OS X prior to El Capitan, users with root access can read plaintext keychain passwords of logged-in users because Apple’s keychain implementation allows these credentials to be cached so that users are not repeatedly prompted for passwords.[2][4] Apple’s `securityd` utility takes the user’s logon password, encrypts it with PBKDF2, and stores this master key in memory. Apple also uses a set of keys and algorithms to encrypt the user’s password, but once the master key is found, an adversary need only iterate over the other values to unlock the final password.[2]
Analyst context for executives and security teams
Securityd Memory is a credential-access technique where an adversary who already has root-level access may read Apple securityd memory to recover material that can unlock a logged-in user’s keychain. The business issue is not initial compromise; it is credential amplification after privileged access, potentially exposing passwords, WiFi secrets, mail/browser credentials, certificates, and secure notes stored in the keychain.
Executive priority
Treat this as a macOS credential-protection and privileged-access readiness issue. Leaders should ask whether older OS X/macOS systems exist, whether root-level activity on endpoints is monitored, and whether incident response playbooks include rapid assessment and rotation of keychain-backed credentials after suspected privileged compromise. It is also useful audit evidence for privileged access monitoring and endpoint credential-store protection.
Technical view
ATT&CK lists this sub-technique under Credentials from Password Stores and credential access, with Linux and macOS platforms, but the supplied description and references are Apple securityd/keychain focused, especially OS X prior to El Capitan. SOC and detection teams should validate coverage for suspicious privileged process access to securityd memory, using the related DET0057 detection-strategy context. IR teams should treat confirmed access as potential keychain credential exposure rather than only local host compromise.
Likely telemetry
- Endpoint process execution and parent/child process context on macOS/Linux systems listed for the technique
- Privilege context showing root or highly privileged execution
- Endpoint detection or audit events indicating process-memory access, debugging, inspection, or unusual interaction with securityd
- macOS securityd/keychain-related activity where available
- Administrative tool usage logs that could explain legitimate privileged inspection activity
Detection direction
- Validate whether endpoint tooling can observe suspicious access to securityd memory; ATT&CK provides no official detection text, but the relationship to DET0057 indicates this is the key detection direction.
- Tune for unusual root-level processes interacting with securityd, especially processes not associated with normal Apple system behavior or approved administration.
- Correlate memory-access signals with recent privilege escalation, new persistence, or suspicious software execution; the Keydnap software relationship provides context that credential theft may coexist with backdoor behavior, but should not be treated as attribution by itself.
- Account for false positives from legitimate security, diagnostic, or administrative tooling that may inspect processes; require allowlisting and change-control evidence rather than blanket suppression.
- Use OS/version context to prioritize legacy macOS/OS X systems because the description specifically calls out pre-El Capitan behavior.
Mitigation priorities
- Reduce the number of users and processes with root-level capability on macOS systems; this technique requires privileged access in the supplied description.
- Prioritize upgrade or retirement of legacy OS X systems, especially pre-El Capitan systems identified in the ATT&CK description.
- Maintain endpoint monitoring capable of recording privileged process behavior and suspicious access to securityd memory.
- Harden administrative workflows so legitimate privileged diagnostics are documented and distinguishable from suspicious activity.
- Prepare IR procedures to rotate or revoke potentially exposed keychain-backed credentials, certificates, and related secrets when credible evidence of securityd memory access exists.
Analyst notes and limits
This object is a sub-technique of T1555 Credentials from Password Stores and is associated with software S0276 Keydnap in the supplied relationships. That relationship is useful for threat-intelligence context, but it does not prove attribution or active exploitation in any environment. The older revoked T1167 object was replaced by this technique, preserving the macOS securityd/keychain focus.
Official ATT&CK detection guidance is not provided. The platforms field includes Linux and macOS, but the supplied technical description and references are Apple securityd/OS X keychain specific, so Linux applicability requires local validation. Detection and exposure depend heavily on endpoint telemetry depth, OS version, and whether root-level activity is centrally monitored.
Securityd Memory
An adversary with root access may gather credentials by reading `securityd`’s memory. `securityd` is a service/daemon responsible for implementing security protocols such as encryption and authorization.[1] A privileged adversary may be able to scan through `securityd`'s memory to find the correct sequence of keys to decrypt the user’s logon keychain. This may provide the adversary with various plaintext passwords, such as those for users, WiFi, mail, browsers, certificates, secure notes, etc.[2][3]
In OS X prior to El Capitan, users with root access can read plaintext keychain passwords of logged-in users because Apple’s keychain implementation allows these credentials to be cached so that users are not repeatedly prompted for passwords.[2][4] Apple’s `securityd` utility takes the user’s logon password, encrypts it with PBKDF2, and stores this master key in memory. Apple also uses a set of keys and algorithms to encrypt the user’s password, but once the master key is found, an adversary need only iterate over the other values to unlock the final password.[2]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1167 | Securityd Memory | Securityd Memory revoked by this object. |
| Enterprise | T1555 | Credentials from Password Stores | This object subtechnique of Credentials from Password Stores. |
Groups, software, and campaigns
S0276: Keydnap
This piece of malware steals the content of the user's keychain while maintaining a permanent backdoor [1].
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.2 | Current bundle | 373df89a0513… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Apple Dev SecurityD
Apple. (n.d.). Security Server and Security Agent. Retrieved March 29, 2024.
Open source URL -
[2]
OS X Keychain
Juuso Salonen. (2012, September 5). Breaking into the OS X keychain. Retrieved November 17, 2024.
Open source URL -
[3]
OSX Keydnap malware
Marc-Etienne M.Leveille. (2016, July 6). New OSX/Keydnap malware is hungry for credentials. Retrieved July 3, 2017.
Open source URL -
[4]
External to DA, the OS X Way
Alex Rymdeko-Harvey, Steve Borosh. (2016, May 14). External to DA, the OS X Way. Retrieved September 12, 2024.
Open source URL -
[5]
mitre-attack T1555.002Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.