AN0150: Analytic 0150
Internal spearphishing via SaaS applications (e.g., Slack, Teams, Gmail): message sent from compromised user with attachment or URL, followed by click and credential access behavior.
Analyst context for executives and security teams
This analytic describes a high-risk SaaS scenario: a trusted internal account sends a phishing message through collaboration or email tools such as Slack, Teams, or Gmail, with a URL or attachment, followed by a user click and credential-access behavior. The business issue is not just phishing; it is loss of trust in internal communications and identity controls after an account is compromised.
Executive priority
Prioritize this as an identity and SaaS resilience question: can the organization quickly recognize when a compromised employee account is being used to phish other users, confirm who clicked, and contain credential exposure? Leaders should ask whether collaboration and email audit logs, URL/click evidence, and identity events are retained and usable for incident response and compliance evidence.
Technical view
Because MITRE provides no official detection logic for AN0150, SOC and detection teams should validate the data chain implied by the description: compromised SaaS user sends internal message with attachment or URL; recipient interacts with it; subsequent activity indicates credential access. Coverage depends on SaaS audit logging, message metadata, attachment/URL visibility, click telemetry, and identity/authentication events. Treat the internal sender as a key context signal, not as proof of legitimacy.
Likely telemetry
- SaaS audit logs for Slack, Teams, Gmail, or comparable collaboration/email platforms
- Message metadata showing sender, recipients, timestamps, channels or threads, attachment presence, and URL presence
- URL click or safe-link/proxy logs where available
- Attachment access or download events where available
- Identity provider and SaaS authentication logs around the sender and recipients
Detection direction
- Correlate internal SaaS messages containing URLs or attachments with recipient click/access events and subsequent identity anomalies.
- Tune for compromised trusted senders: internal-to-internal phishing can bypass controls that focus mainly on external senders.
- Validate whether logs preserve enough message, URL, attachment, and click detail to reconstruct exposure during incident response.
- Use false-positive controls for normal file sharing, business links, automated notifications, and high-volume collaboration workflows.
- Review whether detection coverage spans collaboration tools and email consistently, rather than only the primary mail platform.
Mitigation priorities
- Ensure SaaS audit logging and identity logs are enabled, retained, and accessible for SOC and IR use.
- Strengthen identity controls for SaaS accounts, including MFA enforcement and rapid session/token revocation processes where available.
- Define incident response playbooks for compromised internal SaaS accounts, including message search, recipient notification, credential reset, and containment steps.
- Harden user-reporting and triage workflows so employees can report suspicious internal messages without assuming trusted senders are safe.
- Use awareness and policy controls to reinforce caution with unexpected internal links or attachments.
Analyst notes and limits
AN0150 is a detection analytic in the enterprise ATT&CK domain for SaaS platforms. The supplied object has no tactics, no relationships, and no official detection text, so the take is based on the official description and external reference only.
No relationship context, detection logic, data components, mitigations, procedures, or attribution are supplied. Local SaaS products, logging configuration, retention, and identity architecture will determine practical coverage.
Analytic 0150
Internal spearphishing via SaaS applications (e.g., Slack, Teams, Gmail): message sent from compromised user with attachment or URL, followed by click and credential access behavior.
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 | c87cfd792b77… |
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 AN0150Open 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.