AN0374: Analytic 0374
User-mode application uses flock() or NSDistributedLock to gain exclusive access to a resource file (e.g., /tmp/guard.lock), conditional logic alters execution if already locked.
Analyst context for executives and security teams
This analytic describes a macOS behavior where an application creates or checks an exclusive lock on a resource file, such as a temporary lock file, and changes execution if the resource is already locked. For leaders, the practical value is not that file locking is inherently malicious, but that this pattern can affect how security teams understand process behavior, singleton execution, guard files, and conditional application flow during investigations.
Executive priority
Treat this as a macOS visibility and investigation-readiness question. Security leaders should ask whether SOC and incident response teams can see enough endpoint file, process, and application behavior to explain why a macOS program created or respected a lock file. Because the supplied ATT&CK object has no tactic, relationship, or detection guidance, it should not drive high-priority control spend by itself; it is better used to validate macOS telemetry depth and analyst procedures for distinguishing expected application coordination from suspicious conditional execution.
Technical view
For SOC, detection engineering, and IR teams, validate whether macOS telemetry can show user-mode applications interacting with lock files and changing behavior based on exclusive access. Relevant behavior includes use of flock() or NSDistributedLock and resource files such as /tmp/guard.lock. Since no official detection logic is provided, teams should avoid broad alerting on file locks alone and instead use this as an enrichment or investigation signal tied to process identity, file path, parent process, timing, user context, and whether the behavior is expected for that application.
Likely telemetry
- macOS endpoint process execution metadata, including process name, path, parent process, user, and timestamp
- File creation, open, modification, or access events for lock-like files, especially in temporary paths such as /tmp
- Endpoint security or EDR telemetry that can expose file-locking behavior or related application file access
- Application logs or diagnostic traces showing singleton-instance checks or lock acquisition failures
- Incident response triage artifacts from the affected host, including file system timestamps and process lineage
Detection direction
- Do not treat flock() or NSDistributedLock usage as malicious by default; many legitimate macOS applications use locking for safe resource coordination.
- Baseline known applications that create lock files, especially in temporary directories, and look for unusual process names, locations, users, or execution timing.
- Correlate lock-file behavior with process lineage and surrounding file activity to determine whether the conditional execution path is meaningful.
- Tune detections to reduce false positives from normal application singleton checks, installers, updaters, and service coordination patterns.
- Because ATT&CK provides no official detection text or related techniques for this object, require local telemetry testing before representing this as covered in SOC or audit materials.
Mitigation priorities
- Prioritize macOS endpoint visibility for process and file activity before attempting specific detections for this behavior.
- Maintain application allowlists or baselines for expected lock-file behavior where operationally feasible.
- Ensure incident response playbooks include review of temporary files, lock files, process lineage, and application context on macOS systems.
- Use least privilege and standard endpoint hardening practices to limit the ability of unexpected user-mode applications to run or persist, while recognizing that the supplied object does not define a specific mitigation.
- Document telemetry gaps clearly for compliance and control-readiness discussions, especially where macOS file activity is not centrally collected.
Analyst notes and limits
This is a detection analytic object, not a technique description. It is limited to macOS and describes exclusive file-lock behavior using flock() or NSDistributedLock with conditional execution if already locked. No ATT&CK tactics, relationships, aliases, labels, or official detection logic were supplied, so the main decision value is telemetry validation and investigative context rather than a ready-to-deploy alert.
The source fields do not identify an adversary objective, related ATT&CK technique, active exploitation, prevalence, impact, or detection query. Any determination of suspiciousness requires local baselining, host context, and corroborating telemetry. Coverage claims should not be made from this object alone.
Analytic 0374
User-mode application uses flock() or NSDistributedLock to gain exclusive access to a resource file (e.g., /tmp/guard.lock), conditional logic alters execution if already locked.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.0 | Current bundle | 4f23dded16ad… |
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]
mitre-attack AN0374Open 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.