Multi-factor authentication is an important protection for business accounts. But protecting a login does not protect every way someone can reach your data. Attackers may also reuse stolen session tokens, trick employees into authorizing malicious apps, or exploit access held by a compromised integration vendor. Understanding these paths helps explain where MFA fits and what additional safeguards matter.
Key Takeaways
- MFA remains essential. It helps protect sign-ins, but stolen sessions and some forms of connected-app access may not require a fresh MFA prompt.
- App approval can create lasting access. An OAuth consent screen grants permissions that may remain in place after you close the browser or finish using the app.
- Valid access can still be misused. Attackers may use legitimate accounts, integrations, and export features, making their activity harder to distinguish from normal work.
- Look beyond who can log in. Review connected apps, control new permissions, strengthen administrator authentication, and know how to revoke access.
How Access Continues After Login
When you sign in to a cloud application such as Microsoft 365, Google Workspace, or Salesforce, you do not enter your password and complete MFA with every click. The application uses session information to recognize that you have already authenticated.
Think of a session cookie as a visitor badge issued after you pass a security desk. Your browser presents it as you open email, download files, or view records. If an attacker steals a usable session cookie, they may be able to present it without repeating the original sign-in checks. Whether that works depends on the application’s protections and the restrictions attached to the session.
OAuth: Permission for Connected Apps
OAuth supports the access behind many “Allow” or “Grant Access” screens. You might encounter one when connecting a marketing tool, productivity plugin, CRM integration, or backup service to a work account.
The consent screen describes the permissions the app is requesting. Approving it can let the app access specified email, files, contacts, calendars, or other data without repeatedly asking you to sign in.
The permission grant and the tokens used to exercise that permission are related, but they are not the same thing. An access token lets an app make permitted requests. Depending on the platform and authorization flow, a refresh token may let it obtain new access tokens without another interactive sign-in. That is why closing the app, or changing a password, should not be assumed to remove every form of connected access.
| Access mechanism | What it enables | How it can be misused | Important distinction |
|---|---|---|---|
| Password | Helps authenticate an account during sign-in | An attacker attempts to sign in with stolen credentials | MFA adds another check, so a stolen password alone may not be enough |
| Session cookie or token | Maintains an authenticated session | An attacker attempts to reuse a stolen session | Reuse may avoid a fresh MFA prompt, but session restrictions can affect whether it succeeds |
| OAuth grant and associated tokens | Allow an app to exercise approved permissions | A malicious or compromised app accesses data within those permissions | Removing access may require revoking the grant and associated credentials, not just changing a password |
Three Ways Attackers Gain Access
Stolen passwords, stolen sessions, and abused integrations can lead to similar outcomes, but they are different entry points. Keeping that distinction clear helps businesses choose the right safeguards.
Stolen Credentials and Sessions
Attackers can obtain passwords through phishing, password reuse, or compromised systems. Infostealer malware can also capture saved passwords, browser cookies, and tokens from an infected device.
Another method is adversary-in-the-middle phishing. An attacker places a proxy between the user and the legitimate sign-in service. With susceptible authentication methods, the user can complete sign-in and MFA while the proxy captures session information. The attacker then attempts to reuse that session.
Phishing-resistant authentication, such as appropriately configured FIDO2 security keys and passkeys, helps address this phishing-proxy path. It should not be confused with protection against every form of token theft, particularly theft from an already compromised device.
OAuth Consent Phishing
Consent phishing targets the approval decision rather than just the password. An attacker registers an app and uses email, phone calls, or other social engineering to persuade someone to authorize it.
The consent page may genuinely belong to Microsoft, Google, or another trusted provider. That makes the request look credible, but a genuine approval screen does not mean the app requesting access is trustworthy. If the user approves the request, the malicious app can receive the permissions granted.
Compromised Integration Vendors
A legitimate integration can become an entry point if its vendor is compromised. Attackers who obtain usable customer tokens or other integration credentials may be able to access connected environments within the permissions those credentials allow.
The potential reach depends on which credentials were exposed and what access each customer granted. This makes integration permissions and revocation procedures important even when your own accounts have strong sign-in protection.
What the Reported Incidents Illustrate
Campaigns associated with groups such as ShinyHunters illustrate how attackers can extract data through legitimate accounts, APIs, and export features. However, the incidents do not all demonstrate the same failure:
- Snowflake: Attackers used valid customer credentials on accounts without MFA to query and export data. This illustrates the importance of protecting sign-ins, not a case of stolen sessions bypassing MFA. Snowflake itself was not exploited.
- Vercel and Context.ai: The reported sequence involved infostealer malware on a Context.ai developer’s computer, captured session data including OAuth tokens, and an overly permissive integration used to compromise a Vercel employee’s account.
- Salesforce campaigns: Callers impersonating IT support persuaded employees to authorize malicious connected apps, approve MFA requests, or register attacker-controlled MFA devices. These are distinct actions that can each expand attacker access.
- Salesloft Drift and Gainsight: Reported incidents involved stolen OAuth tokens from trusted integrations being used to access downstream customer environments. The Salesloft incident reportedly affected more than 700 organizations.
The shared lesson is not that MFA is ineffective. It is that login protection, session protection, app permissions, and vendor access address different parts of the problem.
Practical Steps to Reduce Your Risk
Start by understanding which accounts and apps can reach business data. Then establish how new access is approved and how existing access can be removed. The exact settings and procedures will vary by platform.
Start Here
- Build an inventory of connected apps. Review integrations and their permissions in each business platform. In Microsoft 365, Enterprise Applications in the Entra admin center is a starting point, but do not assume one screen captures every integration or credential. Prioritize broad access to email, files, and administrative functions, and investigate connections without a clear current purpose.
- Establish a consent-review process. Decide which permissions users may approve and which require review. Where supported, restrict user consent to appropriate low-risk permissions and trusted publishers. Give employees a straightforward way to request tools rather than leaving them to work around restrictions.
- Use phishing-resistant MFA for administrators. Prioritize privileged accounts for supported FIDO2 security keys or passkeys. This strengthens protection against phishing-mediated sign-ins while other controls address device compromise and session misuse.
- Document and test access removal. Know how to revoke an integration’s permission grants and associated tokens or credentials. Check for related API keys and dedicated service accounts, and assess dependencies before removing them. Do not assume disconnecting an app or changing a password completes the process.
Build Over Time
Review session and device controls. Assess which protections your platforms support, including device requirements, session restrictions, and responses to elevated sign-in risk. In Microsoft 365, Conditional Access and Continuous Access Evaluation may form part of that approach, but their coverage and behavior need to be checked for the applications and scenarios involved.
Watch for access and data-use changes. Useful warning signs include:
- Bulk exports, rapid downloads, or access beyond an account’s expected role
- Sign-ins from unfamiliar devices or locations, or at unexpected times
- Unusual external sharing or transfers to unfamiliar storage services
- Unexpected integrations, new administrative rights, or changes that expand permissions
These signals need context. An unfamiliar location alone does not establish compromise, but unusual sign-in activity combined with abnormal data movement deserves closer investigation.
Limit vendor access. Grant integrations only the permissions they need and review whether those permissions remain appropriate. Where supported, consider shorter-lived credentials. Know how to identify and revoke a vendor’s access if it reports a breach.
Teach employees what approval means. Explain that a real approval screen can still authorize an untrustworthy app. Unexpected callers asking someone to connect an app, approve an MFA prompt, or register an authentication method should trigger a separate verification process, not immediate compliance.
Looking Beyond the Login
Passwords and MFA remain essential, but they are only part of access security. Reducing this risk also requires knowing which apps hold permissions, limiting what they can reach, and being able to recognize and revoke access that is being misused.
A useful first step is to review your connected apps and confirm that each still has a clear purpose. If you would like help with that review, we are happy to take a look.
