AN1130: Analytic 1130
Discovery of connected SaaS applications, APIs, or configurations within platforms like Salesforce, Slack, or Zoom. Defender perspective includes enumeration of available integrations, abnormal querying of service metadata, and follow-on attempts to exploit or persist via discovered services.
Analyst context for executives and security teams
This analytic matters because discovery of connected SaaS applications, APIs, and configurations can reveal how an organization’s cloud business tools are integrated and where access paths may exist. For leaders, the risk is not just reconnaissance: weak visibility into SaaS integrations can leave teams unable to explain which third-party apps, APIs, and configuration metadata are being queried before follow-on misuse or persistence attempts.
Executive priority
Prioritize this as a SaaS governance and monitoring question: can the organization inventory and monitor integrations in business-critical platforms such as Salesforce, Slack, or Zoom? Security leaders should ask whether SaaS administrative activity, API metadata queries, and integration enumeration are logged, retained, reviewed, and usable during incident response or audit evidence requests.
Technical view
The object describes discovery behavior against SaaS platforms, focused on connected applications, APIs, and configurations. SOC and detection teams should validate whether SaaS audit logs expose enumeration of integrations, abnormal service metadata queries, and follow-on attempts involving discovered services. Because no official detection logic or relationships are supplied, teams should treat this as a detection engineering requirement rather than a ready-to-deploy analytic.
Likely telemetry
- SaaS audit logs from supported business platforms
- Administrative activity logs for connected applications and integrations
- API access logs showing metadata or configuration queries
- OAuth or application authorization events where available
- Configuration change logs for SaaS integrations
Detection direction
- Baseline normal SaaS integration and metadata-query activity by user, role, application, and service account.
- Review for unusual enumeration of connected apps, APIs, or configuration metadata, especially by accounts that do not normally administer SaaS integrations.
- Correlate discovery-like activity with subsequent attempts to modify integrations, authorize apps, or otherwise persist via discovered services when such telemetry exists.
- Tune carefully around legitimate administrator, help desk, SaaS engineering, and compliance inventory workflows to reduce false positives.
- Validate logging coverage per SaaS platform; this analytic is likely weak where API, admin, or integration audit events are not collected or retained.
Mitigation priorities
- Maintain an authoritative inventory of connected SaaS applications, APIs, and integrations.
- Restrict SaaS administrative and integration-management privileges to appropriate roles.
- Review and govern connected apps and API access on a recurring basis.
- Ensure SaaS audit logging and retention are sufficient for SOC triage, incident response, and compliance evidence.
- Include SaaS integration discovery scenarios in incident response playbooks and tabletop exercises.
Analyst notes and limits
ATT&CK lists this as detection analytic AN1130 for SaaS platforms and describes discovery of connected SaaS applications, APIs, or configurations in platforms like Salesforce, Slack, or Zoom. The main decision value is validating whether SaaS telemetry can distinguish normal administrative discovery from abnormal enumeration and possible follow-on activity.
No official detection logic, tactics, relationships, mitigations, or procedure examples were supplied. Local SaaS platform capabilities, licensing, log retention, identity context, and normal administrative workflows are required to operationalize this safely.
Analytic 1130
Discovery of connected SaaS applications, APIs, or configurations within platforms like Salesforce, Slack, or Zoom. Defender perspective includes enumeration of available integrations, abnormal querying of service metadata, and follow-on attempts to exploit or persist via discovered 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 | 3cc036215f3e… |
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 AN1130Open 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.