DET0115: Detection Strategy for Spearphishing via a Service across OS Platforms
This detection strategy is intended to help organizations find spearphishing that arrives through third-party services rather than normal enterprise email....
Analyst context for executives and security teams
This detection strategy is intended to help organizations find spearphishing that arrives through third-party services rather than normal enterprise email. That matters because security programs often tune email gateways and mailbox controls heavily, while collaboration, messaging, file-sharing, or other external services may have different logging, identity controls, and response playbooks. For leaders, the practical question is whether initial-access monitoring covers user-targeted messages outside the corporate email path.
Executive priority
Treat this as an initial-access coverage validation item. Executives and security leaders should ask whether SOC visibility, user reporting, incident response procedures, and compliance evidence extend beyond email to third-party services used by employees. The priority is not only blocking messages, but proving the organization can identify suspicious service-originated contact, preserve evidence, and respond quickly when a targeted user interaction may lead to account or endpoint compromise.
Technical view
MITRE provides this as DET0115, a detection strategy for T1566.003 Spearphishing via Service. The supplied object has no official detection text, tactics, platforms, or description of its own, so defenders should anchor validation to the related ATT&CK technique: initial access via third-party services, with related platforms listed as Linux, macOS, and Windows. SOC and detection teams should inventory which third-party services can deliver messages, links, files, invitations, or notifications to users, then confirm whether logs from those services, identity systems, endpoints, and user-reporting channels can be correlated around suspicious inbound contact and subsequent user activity.
Likely telemetry
- Third-party service audit logs for messages, invitations, shared files, comments, notifications, or external contact events
- Identity and access logs showing authentication, new sessions, consent or authorization events, and account changes following suspicious service interactions
- Endpoint telemetry on Windows, macOS, and Linux systems associated with users who received or interacted with service-delivered content
- Network or proxy logs for access to external service links and downloads where available
- User-reported phishing submissions or help desk tickets involving non-email services
Detection direction
- Validate that phishing triage is not limited to enterprise email telemetry; include third-party services that can be used to contact targeted users.
- Correlate suspicious service-originated messages or shares with identity events and endpoint activity for the same user or device.
- Tune for context such as external sender/source, unusual service interaction patterns, unexpected shared content, and follow-on authentication or endpoint activity, while accounting for legitimate business collaboration noise.
- Check blind spots where service logs are unavailable, retained for too short a period, not integrated into the SIEM, or not mapped to user identities consistently.
- Because the ATT&CK object does not provide official detection logic, require local baselining and validation before treating any analytic as reliable coverage.
Mitigation priorities
- Prioritize governance of third-party services that can deliver content or messages to employees, including ownership, logging, retention, and response access.
- Ensure user reporting and SOC triage processes explicitly include suspicious messages received through services outside enterprise email.
- Strengthen identity controls around services used for collaboration, including review of external access and account activity evidence where available.
- Integrate relevant service, identity, endpoint, and network telemetry into incident response workflows so investigators can reconstruct user interaction and follow-on activity.
- Use tabletop or control validation exercises to prove that a reported service-based spearphishing event can be investigated end to end.
Analyst notes and limits
The strongest decision value of DET0115 is coverage scoping: it highlights that spearphishing can enter through third-party services, not just email. This is especially relevant for managed detection, incident response readiness, identity monitoring, and audit evidence because ownership and logs for these services may sit outside traditional email security operations.
The supplied ATT&CK detection strategy object has no official description or detection guidance, and its own platforms and tactics are not specified. Details above are constrained to the relationship showing it detects T1566.003 Spearphishing via Service, which is an enterprise initial-access technique with related platforms Linux, macOS, and Windows. Local service inventory, logging availability, retention, and business workflows are required to determine actual detection coverage.
Detection Strategy for Spearphishing via a Service across OS Platforms
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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 | T1566.003 | Spearphishing via Service Sub-technique | This object detects Spearphishing via Service. |
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.0 | Current bundle | 7f1bf8727cc6… |
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 DET0115Open 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.