Persistent access to OAuth permits and open sessions after commitment is not enough to change the

The threat does not always look like a spectacular explosion; it often enters through the front door because someone opens it. In recent weeks, a repeated pattern has been observed in which attackers combine social engineering with legitimate authentication and administration mechanisms to obtain persistent access to corporate accounts and environments. The most common vectors are not zero-day vulnerabilities, but permissions granted by users or remote sessions that remain open after a commitment. This changes the way it should be answered: it is not enough to change the password.

Technically, the most frequent abuses take advantage of OAuth / SSO's consent flow and persistent sessions of remote support tools or remote access. In the case of OAuth, a malicious application or a forged consent page requests the user permission to act on his or her behalf; if the user accepts, the application receives tokens (access token and often refresh token) that allow you to keep access without the password. These tokens persist until they are explicitly revoked or expired, so a password change does not necessarily eliminate such access. Similarly, attackers use active remote desktop sessions or support software (TeamViewer, AnyDesk, etc.) to maintain a direct channel: closing the local system session does not always revoke the remote control software authorization.

More "classic" techniques that facilitate deception are also being exploited: pages with very similar domains (typosquatting), installation instructions that redirect to malicious installers, and files shared with links that ask for application approval or data access. In parallel, Ransomware and identity theft campaigns continue to use the access obtained through these routes to encrypt data, extract information or deploy command and control (C2) servers hidden behind legitimate services.

Who is affected is wide: individual users whose cloud mail account or services are the key to multiple platforms; small and medium-sized companies that delegate to SaaS applications and employee-delegated consent; and large organizations when SSO configurations, application consent and access policies are not hardened. Confirmed: Permission concessions by users and open remote sessions are practical and recurrent vectors. Estimate: The actual impact is multiplied in environments where there are accounts with administrative roles or access to critical assets; in such cases the attack chain can climb to ransomware or mass data theft. Uncertain: the overall scale of simultaneous campaigns and the exact authority of each operation usually takes time to be confirmed by the response teams and the cloud suppliers.

The practical consequences are clear: persistent access without passwords, post and contact theft, file exfiltration, back door establishment (permissions, service principals, API keys) and ransomware or fraud execution. A crucial point reported by analysts is that Removing the password does not automatically delete tokens issued or remote login closures, so open doors still exist if authorisations and active sessions are not revoked.

What to do now: concrete actions for individual users and for security officials.

For any user: review the applications with access to your account and remove the unknown or unnecessary; check active sessions and close those that you do not recognize; activate the verification in two robust steps (preferably without SMS: FIDO2 keys or authentication applications); and do not accept application permissions that request wide access to mail, files or contacts unless you trust the developer. Google maintains a page to manage connected applications and sessions that is useful as a first step: Manage access to your Google account. In addition, if you use remote support tools, close and check the list of authorized devices and notify the supplier if you suspect abuse.

For equipment and companies: implement administrative consent policies that limit users' ability to accept non-revision third party applications; enable white lists of approved applications; audit delegated consent and provide specific training on consent phishing (how to recognize OAuth's legitimate requests against imitations). In Microsoft / Azure environments, review and manage the business application permissions through the Azure AD portal and consider revoking grant approvals to suspicious applications; Microsoft offers documentation to manage the consent and application permissions in Azure AD: Manage application consent.

Other necessary technical measures include forcing the closure of sessions and the revocation of tokens after incidents (in some suppliers there is the option to revoke refresh tokens or "revoke sessions"), deactivating legacy authentication protocols that do not support MFA, enabling conditional access policies (by location, device and risk), rotation of keys and application secrets, and monitoring of log to detect unforeseen consent concessions or the creation of primary service. It is also good practice to restrict application permits to the least privilege necessary and to use EDR tools to detect and block unusual data transfers or execution of administrative tools by unauthorized processes.

In short, the normality of these intrusions - a call, a shared file or a "Allow" button - requires that the permit granted be treated as a security risk in itself. The effective response combines explicit revocation of permits and sessions, tightening of consent policies, and preventive controls such as strong MFA and white application lists. To review what you already have access to before adding something new is, for now, the most practical and efficient rule to reduce the attack surface.