Sipping my morning coffee while “suspicious login” notifications flood my phone, or receiving a panicked call from a user screaming, “Mehmet, I can’t log in, it’s not accepting my password!”… Over the years, I have seen dozens of variations of this scenario in the field.
Losing control of an account—especially a critical email or cloud infrastructure account—is not the end of the world. However, panic-driven mistakes can turn a minor leak into a disaster that destroys an entire company or your personal digital footprint. The first thing most people do is repeatedly click the password reset link, but if the attacker has already dug other tunnels inside, this move is completely useless.
In this guide, I will explain the technical details of exactly what order you should act in with a cool head during those critical first 60 minutes when you realize an account has been compromised. We won’t just say “it happens”; this time, we will systematically roll back the steps of the attacker who has taken full control.
Symptom Analysis: Are You Actually Hacked, or Is It a Temporary Error?
When you cannot access an account or notice strange activity, the first thing you need to do is assess the situation. Sometimes, a temporary negative caching issue on your DNS server, or a regional outage from your service provider (such as Microsoft 365 or Google Workspace), might lock you out. Before entering panic mode, you must determine whether the system is actually controlled by an attacker or if it is just a technical glitch.
If you see a “your session has expired” warning in your browser or email client and cannot log in with your old password, you should immediately perform a verification test. If you manage a corporate account, you should ask a colleague with admin panel access or use your monitoring tools to pull the session logs for the user in question. For example, if you see a successful login from an unexpected geographical location in the user’s Azure AD (Entra ID) or local Active Directory sign-in logs, this is a definitive indicator of a compromise.
The JSON log example below shows a typical successful but suspicious login event. The key point to notice here is that while the user normally logs in from Bursa, seconds later they accessed the system from a completely different IP block with an unusual User-Agent:
{
"timestamp": "2026-06-26T08:14:22Z",
"event_type": "UserLoginFailedAndSucceeded",
"user_principal_name": "mehmet@domain.local",
"source_ip": "185.220.101.5",
"geo_location": {
"country": "Unknown/TorExitNode",
"city": "Unknown"
},
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0",
"authentication_method": "Password",
"result": "SuccessWithBypass"
}If you see a successful login in the logs coming from a foreign IP address like the one above, especially one that has somehow bypassed the MFA (Multi-Factor Authentication) step, your diagnosis is confirmed. It is time to move past the analysis phase and start active mitigation.
Step One: If You Have Access, Immediately Trigger “Revoke All Sessions”
The biggest and most fatal mistake I see in the field is this: as soon as users realize their account is compromised, they only change their password and think the job is done. However, modern authentication systems (OAuth 2.0, SAML, etc.) issue a “Refresh Token” and an “Access Token” to the browser or application after the password is verified. Even if you change the password, the valid session cookie or refresh token in the attacker’s hands remains active. The attacker can continue to roam inside the system for hours, or even days, after you change the password.
Therefore, the very first action to take, even BEFORE changing the password, is to force-terminate (revoke) all current active sessions and tokens. This action immediately invalidates the session in the attacker’s browser and forces them to re-authenticate.
If you are responding to an account compromise in a Microsoft 365 (Azure AD / Entra ID) environment and have admin privileges, you should run the following PowerShell command series to terminate all sessions for the user. This command will instantly invalidate the browser and application tokens of the user across all devices:
# Terminating sessions using the Microsoft Graph PowerShell module
Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All"
# Specify the Object ID or UPN of the suspicious user
$UserUPN = "target_user@yourdomain.com"
# Instantly revoke all sessions and refresh tokens
Revoke-MgUserSignInSession -UserId $UserUPN
# Check the user's status to verify the process was successful
Write-Host "All active sessions for the user have been successfully terminated." -ForegroundColor GreenStep Two: Password Change and Clearing MFA/2FA Settings
After terminating the sessions, we can now proceed to setting a new password. However, the trap here is this: once inside, the first thing an attacker usually does is open a “backdoor” for themselves. This backdoor is typically adding an Authenticator app under their control (TOTP seed) or their own phone number as a second MFA method to the account. Even if you change the password, when the system prompts for MFA, the approval code will go to the attacker’s phone or app.
For this reason, immediately after (or simultaneously with) changing the password, you must reset all MFA devices in the account’s security settings. You must delete old devices, check registered phone numbers, and if necessary, disable MFA entirely and rebuild it from scratch with a secure device (such as a hardware key matching RFC 6238 standards or an Authenticator controlled by the company).
If you are a system administrator and want to reset a user’s MFA methods, you can do this directly from the respective cloud console or trigger it via an administration panel or script like the one below. The following command clears all registered strong authentication methods (MFA) for the user:
# List and clear all registered MFA methods of the user
Get-MgUserAuthenticationMethod -UserId $UserUPN | Foroughly-Clean
# Alternatively, force the user to re-register MFA
Update-MgUser -UserId $UserUPN -StrongAuthenticationRequirements @()When setting the new password after clearing the MFA methods, never use variations of old passwords (for example, instead of Company2026!, do not use Company2026?). Set a completely random password of at least 16 characters generated by a password manager. At this stage, against the possibility of an infostealer virus on the local computer, absolutely do not perform the password change from that suspicious computer; use a secure mobile device or another clean computer that you are sure is safe.
Step Three: Revoke Third-Party Application (OAuth) Permissions
Attackers are very smart now. They don’t just settle for stealing your password; once they get into the account, they use “Malicious OAuth Applications” (Consent Phishing) to maintain access even if you change the password in the future. They go to your account settings and grant broad permissions to an API integration they wrote or manipulated (for example, an application disguised as “PDF Converter” or “Calendar Sync”). This application can read your emails, send files, or steal your contacts directly via the API, completely independent of your password.
This is one of the most insidious edge cases in cloud security. The user changes their password, resets MFA, thinks everything is clean, but a malicious Azure AD enterprise application running in the background silently continues to exfiltrate data.
Below is an example API response showing the authorization scopes of a malicious OAuth application defined on a user’s account. The Mail.ReadWrite and Mail.Send permissions here allow the attacker to send and read emails without needing a password:
{
"id": "oauth_app_982317",
"display_name": "Free PDF Reader Online",
"publisher_domain": "attacker-controlled-domain.xyz",
"permissions_granted": [
"User.Read",
"Mail.ReadWrite",
"Mail.Send",
"Files.ReadWrite.All"
],
"consent_type": "Principal",
"created_datetime": "2026-06-26T07:45:10Z"
}If you see such an application, the only thing you need to do is immediately revoke that application’s consent. If you are using Google Workspace, remove it from the “Third-party apps with account access” menu; if you are using Microsoft 365, delete this application entirely from “Enterprise Applications” or the user’s “Consent and Permissions” tab. Never say “I recovered the account” without performing this cleanup.
Step Four: Audit Email Forwarding Rules and the Sent Items Folder
The second favorite insidious method of attackers is to silently slip into your email inbox and create a “forwarding rule” (inbox rule). They do this a lot, especially in finance, accounting, or C-level executive accounts. They automatically forward all incoming messages containing words like “invoice”, “payment”, “bank”, “password”, “swift” to an external email address they control, and immediately delete these forwarded emails from your inbox. This way, you share all your commercial correspondence with the attacker without even realizing it.
Therefore, once you have securely regained access to the account, one of the first things you must do is inspect the rules tab of your email client (Outlook, Gmail, etc.) line by line.
The following PowerShell command lists all forwarding rules in the mailbox of the suspicious user on Exchange Online. With this command, you can quickly detect rules created without the user’s knowledge:
# List all rules in the suspicious mailbox
Get-InboxRule -Mailbox $UserUPN | Select-Object Name, Enabled, RedirectTo, MoveToFolder, Description | Format-Table -AutoSize
# If you find a suspicious rule forwarding to an external address, delete it like this:
# Remove-InboxRule -Mailbox $UserUPN -Identity "SuspiciousRuleName" -Confirm:$falseDo not stop there; check the “Sent Items” and especially the “Deleted Items” folders. Attackers often send emails containing fake invoices or malicious links to your clients or business partners on your behalf while you are logged in, and then immediately delete them to leave no trace. If there is an email in the Sent folder that you did not write, you must immediately warn the recipients of that email.
Step Five: Stop the Domino Effect on Other Linked Accounts and Start Tracking
An account compromise is rarely limited to a single account. Our digital world is like a tightly coupled chain of dominoes. The compromised email address is the “password reset” hub for your bank accounts, government portals, SaaS tools you use, or other platforms you are subscribed to. Once the attacker controls the primary email, they can start resetting your passwords on other platforms using this email.
Therefore, after completing the first four steps and securing the primary account, you must check all critical services associated with this account one by one (especially financial tools, primary server management panels, domain registrars, and password managers). Scan your email history (and deleted emails) again to see if any password reset requests were made on these platforms.
Additionally, you must analyze your system logs to find the source of the leak. How did the attacker get in? Did you click on a phishing email, or did an infostealer malware infecting your computer steal all your passwords and cookies from your browser? If the issue is session hijacking (cookie theft), entering new passwords without completely isolating and formatting or deeply cleaning that computer will just result in the new passwords being stolen again.
The simple table below summarizes common leak methods and the specific measures you should take against them:
| Attack Method | Sign / Symptom | First Action to Take |
|---|---|---|
| Session Hijacking (Cookie Theft) | Direct login to the system without prompting for password and MFA. | Isolate the device from the network, terminate all active sessions (Revoke Sessions). |
| Phishing | User entering password and one-time MFA code into a fake page. | Change the password immediately, audit MFA methods. |
| Credential Stuffing | Login resulting from the leak of the same password used across different platforms. | Generate a unique password for each account using a Password Manager. |
| Malicious OAuth App | Email leakage continuing in the background even if the password changes. | Completely revoke third-party application permissions (App Consents) from account settings. |
Conclusion: The Next Step
After recovering your account by applying the above 5 steps in the correct order, one final step remains to completely close the process: tightening your security baseline.
As a first step, consider using hardware security keys (devices like YubiKey matching the FIDO2/WebAuthn standard) on all your critical accounts. These keys form the most resilient line of defense against session hijacking and phishing attacks. Also, enable logging and observability tools (such as anomalous geographic login alarms with Grafana/Loki integration) on all systems you use so that next time there is a leak, you can notice it in the first minute, not the first hour.
Your next step should be to clear all browser history and saved passwords on your computer, and harden your operating system with the latest security patches. Stay safe, but remember: in the digital world, there is no absolute security, there is only being prepared.