AN1753: Analytic 1753
Defender observes anomalous signaling network queries targeting subscriber information associated with a device, including unexpected routing requests, location information exchanges, or node-origin inconsistencies indicative of SS7 signaling abuse. [1] The CSRIC also suggests threat information sharing between telecommunications industry members.
Analyst context for executives and security teams
This analytic is about spotting abnormal telecom signaling activity that may expose subscriber or device-related information, such as unexpected routing or location-related queries. For leaders, the practical significance is that mobile security risk may sit outside normal endpoint telemetry: visibility may depend on carrier, signaling-network, or telecommunications partner data rather than the Android device alone.
Executive priority
Prioritize this as a resilience and third-party visibility question for organizations with material mobile, telecom, or cyber-physical dependencies. Executives should ask whether the organization has access to telecom signaling abuse indicators through providers, industry sharing, or incident response agreements, and whether mobile-related investigations can incorporate carrier-side evidence when device telemetry is insufficient.
Technical view
The supplied ATT&CK analytic applies to Android in the mobile domain and focuses on anomalous signaling network queries associated with subscriber information. SOC and IR teams should validate whether they can obtain evidence of unexpected routing requests, location information exchanges, or node-origin inconsistencies from telecom providers or relevant internal telecom infrastructure. Because ATT&CK provides no separate detection logic for this object, detection engineering should treat the description as a validation objective rather than a ready-to-deploy rule.
Likely telemetry
- Telecommunications signaling logs or alerts related to subscriber information queries
- Records of routing requests involving mobile subscribers or devices
- Location information exchange records available through carrier or telecom infrastructure sources
- Originating node identifiers and consistency checks for signaling messages
- Threat information sharing reports from telecommunications industry partners where available
Detection direction
- Confirm whether signaling-network visibility exists; Android endpoint logs alone are unlikely to prove or disprove this behavior.
- Baseline expected routing, location, and subscriber-information query patterns with telecom partners or internal telecom teams before alerting on anomalies.
- Validate node-origin inconsistencies and unexpected query paths against legitimate roaming, carrier operations, maintenance activity, and lawful business processes to reduce false positives.
- Establish escalation paths for carrier-side evidence requests during mobile incidents, since the analytic depends on data that may not be held by the enterprise SOC.
- Use telecommunications threat information sharing where available, consistent with the CSRIC reference noted by ATT&CK.
Mitigation priorities
- Start with governance: identify business processes and critical services that depend on mobile subscriber integrity, location confidentiality, or carrier availability.
- Establish incident response and evidence-sharing procedures with telecommunications providers before an incident occurs.
- Define what subscriber, routing, and location-query telemetry can be retained, shared, and reviewed within legal and privacy constraints.
- Integrate telecom-side indicators into SOC playbooks for mobile incidents rather than relying only on device EDR or MDM evidence.
- Review compliance and privacy obligations for handling subscriber and location-related data.
Analyst notes and limits
This is a detection analytic, not a full technique description. Its value is in highlighting that meaningful detection may require telecom signaling visibility and industry coordination. The only supplied reference is the CSRIC legacy systems risk reduction report plus the MITRE analytic URL.
ATT&CK supplies no tactic, no relationship context, and no formal detection logic for this object. Local feasibility depends heavily on carrier cooperation, telecom infrastructure access, data retention, privacy constraints, and whether the organization has operational need for this level of mobile signaling visibility.
Analytic 1753
Defender observes anomalous signaling network queries targeting subscriber information associated with a device, including unexpected routing requests, location information exchanges, or node-origin inconsistencies indicative of SS7 signaling abuse. [1] The CSRIC also suggests threat information sharing between telecommunications industry members.
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.1 | Current bundle | a9abb3129710… |
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]
CSRIC5-WG10-FinalReport
Communications Security, Reliability, Interoperability Council (CSRIC). (2017, March). Working Group 10 Legacy Systems Risk Reductions Final Report. Retrieved May 24, 2017.
Open source URL -
[2]
mitre-attack AN1753Open 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.