Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1498: Analytic 1498

Applications or launchd services invoking RSA or public-key routines from the Security framework, followed by outbound SSL/TLS sessions with unrecognized certs or anomalous handshakes. Defender observes unified logs of API calls and suspicious network entropy.

EnterpriseAN1498AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because it focuses on a macOS pattern where an application or launchd service uses RSA/public-key functions from Apple’s Security framework and is then associated with outbound SSL/TLS activity that looks unusual, such as unrecognized certificates or anomalous handshakes. For leaders, the value is not in the cryptography call alone; it is in validating whether endpoint and network teams can connect local macOS behavior to suspicious encrypted communications quickly enough to support triage and incident response.

Executive priority

Prioritize this as a coverage-validation item for macOS fleets, especially where business-critical users, developers, administrators, or regulated data workflows depend on macOS systems. The key decision is whether the organization can produce credible evidence across endpoint unified logs and network TLS observations when suspicious encrypted communications originate from macOS applications or launchd services. This supports incident decision-making, audit evidence for monitoring controls, and budget choices around endpoint logging, network telemetry, and SOC correlation capability.

Technical view

SOC and detection teams should validate whether macOS unified logs capture relevant Security framework API activity and whether those events can be correlated with outbound SSL/TLS sessions showing unrecognized certificates, anomalous handshakes, or suspicious network entropy. Because no ATT&CK tactic, technique relationship, or official detection logic is supplied, this should be treated as a detection-strategy analytic rather than a complete rule. Practical validation should focus on event availability, process attribution, launchd service context, destination metadata, certificate characteristics, and time-window correlation between local cryptographic API use and outbound TLS behavior.

Likely telemetry

  • macOS unified logs showing Security framework RSA or public-key routine usage
  • Process and application identity associated with the API activity
  • launchd service context where applicable
  • Outbound SSL/TLS session metadata from network sensors, host telemetry, or proxy logs
  • Certificate details for outbound TLS sessions, including whether certificates are recognized or unusual in the local environment

Detection direction

  • Confirm that macOS unified logging is retained and searchable for Security framework API activity at useful fidelity.
  • Correlate cryptographic API use with outbound TLS sessions by host, process where available, destination, and time proximity.
  • Tune around known legitimate macOS applications, enterprise agents, developer tools, and services that commonly perform public-key operations and TLS communications.
  • Treat unrecognized certificates and anomalous TLS handshakes as context, not proof of malicious activity; local baselines are required.
  • Validate whether launchd-launched processes are distinguishable from normal user-launched applications in the available telemetry.

Mitigation priorities

  • Establish reliable macOS endpoint logging and retention before attempting high-confidence alerting.
  • Ensure network monitoring or proxy telemetry can preserve TLS certificate and handshake metadata where policy and privacy requirements allow.
  • Baseline normal macOS application and launchd service behavior for cryptographic API use and outbound TLS destinations.
  • Create SOC triage procedures that combine endpoint process context, launchd persistence context, certificate review, and destination reputation using approved internal sources.
  • Use findings from validation to guide control priorities such as macOS logging configuration, network visibility, endpoint detection coverage, and incident response evidence collection.
Analyst notes and limits

The supplied object is a MITRE detection analytic for macOS, not a full ATT&CK technique entry. It provides a behavioral description but no official detection logic, tactics, related techniques, or relationship context. The most defensible use is as a prompt to test whether macOS endpoint and network telemetry can be correlated around cryptographic API use and suspicious TLS behavior.

This take is limited to the supplied STIX fields and external reference. No active exploitation, adversary attribution, business impact, or guaranteed detection coverage is stated. The analytic does not specify a tactic, related ATT&CK technique, concrete data components, thresholds, or false-positive examples, so local environment baselines and telemetry testing are required.

Official MITRE ATT&CK definition

Analytic 1498

Applications or launchd services invoking RSA or public-key routines from the Security framework, followed by outbound SSL/TLS sessions with unrecognized certs or anomalous handshakes. Defender observes unified logs of API calls and suspicious network entropy.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
b916e1198349ab24...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle b916e1198349…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1498
    Open source URL
Source and licensing

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.