SOQL reconnaissance is the use of Salesforce Object Query Language to map an environment, count records, and identify high-value objects or fields. Attackers use it to learn what data exists, where sensitive information may sit, and which queries are most likely to expose credentials or other valuable records.
Expanded Definition
SOQL reconnaissance is a discovery technique, not a query style used for ordinary reporting. It uses Salesforce Object Query Language to enumerate objects, count records, and infer which fields or relationships may reveal sensitive business data, privileged context, or usable credentials. The boundary that matters is intent: defensive administrators may run similar queries for inventory and validation, while attackers use the same language to reduce uncertainty before deeper abuse.
In practice, the value of SOQL reconnaissance comes from metadata visibility as much as content visibility. A small result set can still reveal where high-value data lives, which object names imply customer, finance, or identity records, and which fields are likely to be useful in follow-on access. Usage in the industry is fairly stable, although the exact playbook varies across tenants and permission models. The key misunderstanding is treating SOQL as merely a data retrieval tool rather than a way to map the structure of an accessible Salesforce environment.
Examples and Use Cases
Security teams and attackers may use SOQL in different ways, but the mechanics are similar: the query exposes what the caller can see and what the environment contains. That makes the technique useful for both asset discovery and abuse preparation.
- Counting records in objects such as accounts, cases, contacts, or custom objects to estimate where sensitive or operationally important data resides.
- Listing field names and relationship paths to identify likely secrets, identifiers, or exports that can be queried next.
- Testing whether restricted objects return data at all, which helps infer permission gaps and unintended exposure.
- Mapping business objects that suggest downstream value, such as payroll, support, token, integration, or credential-related records.
- Using query responses to decide which data to exfiltrate first when time, rate limits, or monitoring pressure are present.
One practical tradeoff is that richer query access improves administration and troubleshooting, but it also enlarges the reconnaissance surface if the same permissions are available to a compromised user or integration.
Security Implications
SOQL reconnaissance matters because discovery is often the first step in a larger compromise chain. Once an attacker can see which objects exist and how they are named, they can focus effort on the most valuable records instead of guessing. That reduces noise, accelerates abuse, and increases the odds that later queries will return credentials, tokens, customer data, or other high-impact information.
The failure mode is usually not a single dramatic exploit. It is a gradual loss of visibility control: permissive API access, overly broad read permissions, weak monitoring of unusual query patterns, or integration accounts that can inspect more than they should. NHIMG research on exposed secrets shows how quickly attackers move once credentials are available; public AWS credentials are attempted within an average of 17 minutes, with some attempts in 9 minutes, which is a reminder that reconnaissance and exploitation can be tightly coupled.
When SOQL reconnaissance is missed, the observable symptoms are often subtle: unusual object enumeration, repeated field probing, or spikes in query volume against rarely used data structures. Those signals are valuable because they can reveal intent before data leaves the environment.
Domain and Governance Relevance
SOQL reconnaissance sits at the intersection of application governance, data exposure control, and identity-bound access in Salesforce environments. The term matters in NHI security because many Salesforce access paths are used by service accounts, integrations, automations, or API clients rather than only human users. If those non-human identities can query broadly, reconnaissance becomes a practical precursor to secrets discovery, mass export, or privileged business-data exposure.
The governance question is therefore not just whether SOQL is enabled, but which identities can use it, against which objects, and with what monitoring. That changes how teams think about least privilege, logging, and offboarding for integration credentials. It also means query capability should be treated as a data-access control, not merely a developer convenience. For NHI-focused environments, the relevant boundary is whether a machine identity can use query access to reveal more of the tenant than its function requires.
OWASP Non-Human Identity Top 10 is useful background when SOQL access is granted to integrations or service identities that should not be able to enumerate sensitive objects broadly.
Risk and Threat Considerations
SOQL reconnaissance creates material exposure because Salesforce query access can be used to map data structures, locate sensitive objects, and identify the most promising targets for exfiltration or privilege abuse. The risk is highest when the same query capability is available to compromised integrations, over-permissioned service accounts, or users whose access is broader than their role requires.
Failure mechanism: An attacker with query access enumerates objects and fields, infers where secrets or valuable records are stored, and then narrows follow-on queries to high-value data. Weak object-level controls, excessive read permissions, and insufficient monitoring allow this probing to blend into routine API activity.
Impact: Sensitive records can be discovered faster, exfiltrated in larger volume, and targeted more precisely. The result may be credential theft, customer-data exposure, business-process disruption, or broader compromise through downstream systems that trust Salesforce-stored data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | SOQL recon can surface records that expose machine secrets or tokens. |
| NHI-03 — Access Governance | Recon succeeds when identities can query beyond their intended data scope. | |
| NHI-06 — Monitoring and Detection | SOQL enumeration is a detectable precursor to targeted data access. | |
| Recommendation — Restrict query paths that can reveal secrets and rotate exposed credentials quickly. Constrain each non-human identity to the minimum Salesforce objects and fields it needs. Alert on unusual object enumeration and repeated field-probing query patterns. | ||
| CIS Controls v8 | 6.3 — Data Recovery | Recon often precedes data exposure that demands recovery and containment readiness. |
| 8.2 — Audit Log Management | Query abuse is only visible if API and object-access logs are retained and reviewed. | |
| Recommendation — Prepare containment and recovery procedures for data accessed through overbroad queries. Centralize Salesforce query logs and review them for enumeration behavior. | ||
| MITRE ATT&CK | T1087 — Account Discovery | SOQL recon maps which accounts and related records exist in the tenant. |
| Recommendation — Map suspicious SOQL enumeration to discovery activity and hunt for staged abuse. | ||
Practitioner Guidance
What to watch for: Treat repeated object enumeration, unexpected field probing, and query patterns against low-use or high-value objects as investigation triggers. These behaviors often indicate discovery activity before any obvious data loss appears.
Governance implication: SOQL access should be reviewed as part of non-human identity governance, because integrations and automations often have enough reach to become reconnaissance platforms if their scopes are not tightly limited. The practical question is whether each machine identity can query only the objects it truly needs.
Practitioner takeaway: Query capability is an access decision, not just a developer convenience, so ownership of SOQL reach should sit with the same rigor used for other sensitive data pathways.
Related resources from NHI Mgmt Group
- How can organisations detect AI reconnaissance before exploitation?
- What breaks when an AI agent can chain reconnaissance, exploitation, and exfiltration?
- Why do diplomatic phishing campaigns often mix reconnaissance and delivery?
- Why does reconnaissance matter as much as the exploit itself in AppSec detection?
