What are the signs that a third-party app consent campaign is being used for account reconnaissance?

What account reconnaissance looks like inside a consent lure

A third-party app consent campaign becomes reconnaissance when the attacker is not trying to win access immediately, but to learn which identities, tenants, and permissions are worth pursuing. The tell is often the scope set itself: low-friction requests for basic directory, profile, or mailbox access can be enough to validate who responds, what tenant controls exist, and whether the target will approve a harmless-looking prompt.

That pattern matters because reconnaissance campaigns usually aim to separate a curious user from a hardened one, then map the tenant for later abuse. A consent screen is not only an authorization step, it is also a collection point for signals about user behaviour, language, trust anchors, and the organisation’s review process.

Why basic scopes are a warning sign, not reassurance

Requests such as Contacts.Read, People.Read, User.Read, or Mail.Read can look mundane, but in a campaign they are often chosen because they are easy to justify in a lure and still reveal useful intelligence. Those scopes can expose directory structure, relationship graphs, mailbox metadata, and active-user behaviour, which is enough to support follow-on targeting even if the application never requests obviously dangerous permissions.

Look closely at the mismatch between the stated business need and the permission set. A legitimate productivity app usually has a clear functional reason for the access it asks for, while a reconnaissance lure tends to be vague, overbroad for the advertised purpose, or oddly timed. The question is not only whether the scope is high privilege, but whether the scope is plausibly necessary for the app you were shown.

When the request comes from a trusted-brand impersonation or a local-authority spoof, the low-scope design is itself part of the deception. It is meant to reduce friction long enough for the attacker to confirm whether the user, tenant, or consent workflow is exploitable. NHIMG’s Salesloft OAuth token breach and Klue OAuth Supply Chain Breach both show how third-party trust can be converted into broad downstream access once a consented app is allowed to operate.

How the redirect chain reveals reconnaissance activity

The second major sign is pathing. If a user reaches the Microsoft consent page from a suspicious message, a shortened link, or a redirect chain that ends on an attacker-controlled domain after denial or approval, the campaign is using the flow itself as telemetry. That redirect chain can reveal whether the victim clicked, whether the tenant exists, and whether the user passed through an authentication or consent boundary that the attacker can exploit again.

Reconnaissance campaigns often rely on intermediate domains, trackers, or consent wrappers to observe user interaction before any actual payload is needed. A clean-looking Microsoft consent screen does not make the journey trustworthy if the preceding hop is deceptive or if the post-consent landing page is unrelated to the advertised service. In practice, the surrounding domain choreography is often more suspicious than the permission prompt itself.

This is also where third-party app abuse overlaps with identity and authorization abuse. The app may not need to steal a password if it can persuade a user to authorize a token or reveal tenant metadata. OAuth-based access paths can be legitimate, but they become reconnaissance tools when the attacker uses consent as a low-noise discovery channel. OWASP Non-Human Identity Top 10 is useful here because it frames consented third-party access, secret handling, and overprivilege as governance and abuse problems, not just technical integration details.

What separates routine third-party access from consent reconnaissance

The best discriminator is behavioural context. A real business app usually has a known publisher identity, a predictable onboarding path, and a permission pattern that matches the advertised workflow. Reconnaissance lures often show the opposite: urgent language, vague utility claims, inconsistent branding, recycled templates across tenants, and a consent prompt that appears after a suspicious referral path rather than from a normal admin workflow.

If the campaign is exploratory, you may also see repeated consent attempts against the same tenant, requests that change slightly between runs, or messaging that seems designed to test user trust rather than to deliver functionality. The attacker’s goal is to learn which tenants will consent, which users are likely to approve, and which identity surface is easiest to revisit later.

For a deeper read on the underlying access pattern, the RFC 6749: The OAuth 2.0 Authorization Framework and RFC 8693: OAuth 2.0 Token Exchange help explain why consent and delegation can be abused as an access path when the trust decision is weak.

Risk and Threat Considerations

Consent reconnaissance is dangerous because it can look like low-risk access while still leaking the information an attacker needs to plan the next step. Even a small permission set can reveal enough tenant, mailbox, or relationship data to support targeted phishing, follow-on token abuse, or broader identity compromise.

Failure mechanism: The attacker abuses the consent flow as an intelligence-gathering channel, using benign-looking scopes, deceptive branding, and redirect telemetry to identify responsive users and viable tenants.

Impact: Organisations can miss the campaign until the same app, publisher pattern, or domain chain is reused for broader access, token theft, or data collection.

Practitioner Guidance

What to verify: Treat consent requests as suspicious when the publisher, domain chain, and requested scopes do not line up with a known business need. The most important check is whether the app would still make sense if you removed the marketing copy and looked only at the access it is asking to receive.

What good looks like: Consent requests should be rare, expected, and attributable to a known workflow, with users able to explain why the app exists and why the permissions are needed. If the app cannot be tied to a real owner or a documented business process, treat the approval path as hostile until proven otherwise.

Practitioner takeaway: Reconnaissance campaigns often succeed by making the consent decision feel routine, so the decisive control is not just blocking bad permissions, it is challenging any consent path whose branding, redirect chain, and business justification do not align.

Related resources from NHI Mgmt Group

• What breaks when organisations cannot see third-party app consent clearly?
• How should security teams govern third-party SaaS app consent so access does not outlive the approving user?
• What is the difference between an internal service account and one used by a third-party cloud service?
• What are the signs that a collaboration app account takeover campaign is becoming a broader identity problem?