AN0743: Analytic 0743
Background launch agents/daemons with high CPU use and network access to external mining services.
Analyst context for executives and security teams
This analytic is about macOS background Launch Agents or Daemons that consume high CPU while connecting to external mining services. For leaders, the practical issue is not just a noisy endpoint: unauthorized mining can degrade device performance, increase operational friction, and indicate weak control over persistent background software on macOS assets.
Executive priority
Prioritize this as a macOS endpoint governance and resilience check. Security leaders should ask whether the organization can identify persistent background services, prove which ones are approved, and correlate endpoint resource abuse with outbound network activity. This is useful for SOC readiness, incident triage, and compliance evidence around endpoint monitoring and software control.
Technical view
SOC and IR teams should validate whether macOS telemetry can connect three elements: Launch Agent/Daemon persistence, sustained high CPU usage, and outbound access to external mining services. Because no official detection logic is provided and no ATT&CK relationships are supplied, teams should treat this as a detection concept requiring local baselining and tuning rather than a ready-to-deploy rule.
Likely telemetry
- macOS Launch Agent and Launch Daemon inventory, including plist paths and configured executables
- Endpoint process telemetry with CPU utilization over time
- Process-to-network connection telemetry from macOS endpoints
- DNS, proxy, firewall, or network security logs showing outbound access to external mining services
- Endpoint file and configuration change records for launchd-related locations
Detection direction
- Correlate background launchd persistence with abnormal or sustained CPU consumption and outbound mining-service network activity.
- Baseline legitimate macOS management, backup, security, and developer tools that may run as background agents and consume CPU to reduce false positives.
- Validate visibility on both user-level Launch Agents and system-level Launch Daemons; missing either creates a material blind spot.
- Use network context to distinguish generic high CPU activity from suspected mining behavior, but avoid relying only on domain or destination lists because local environments and service naming change.
- Confirm the SOC can pivot from the launch item to the executable, process tree, user context, network destinations, and affected host for incident response.
Mitigation priorities
- Maintain an approved inventory of macOS Launch Agents and Launch Daemons and review unapproved additions or changes.
- Apply endpoint monitoring that captures persistence configuration, process resource usage, and network activity on macOS systems.
- Use egress controls and network monitoring to limit and investigate connections to known or suspicious external mining services.
- During response, validate business legitimacy before removal, then disable unauthorized launch items and associated executables using standard IR procedures.
- Review macOS fleet management and least-privilege practices to reduce unauthorized persistent background software.
Analyst notes and limits
The supplied object is a detection analytic for macOS only. It describes background launch agents/daemons with high CPU use and network access to external mining services. There are no supplied tactics, relationships, aliases, or official detection logic, so this take focuses on defensive validation and telemetry requirements rather than a specific ATT&CK technique mapping.
This assessment is limited to the supplied ATT&CK fields and external reference. It does not establish active exploitation, attribution, prevalence, impact, or guaranteed detectability. Local baselines, approved software inventories, and endpoint/network telemetry quality are required to determine whether this behavior is suspicious in a specific environment.
Analytic 0743
Background launch agents/daemons with high CPU use and network access to external mining services.
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 | c3c013096e8a… |
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 AN0743Open 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.