Your Password Reset Will Not Save You

Hacker Connect
1

You can force a password reset across the company tonight. If an attacker already holds a valid session token, that reset changes nothing. The application already trusts the session.

On 21 May 2026, the FBI Internet Crime Complaint Center issued a public warning about a Phishing-as-a-Service platform named Kali365. The victim completes a genuine Microsoft login and a real MFA prompt. Everything looks normal from their side. The operator still walks away with persistent access.

No password is intercepted. MFA is satisfied. Your logs stay clean.

That last part is the problem. Most security teams are waiting for an alert that will never fire, because the exploitation step does not produce one.

We broke down how these kits work, why your email gateway and your SIEM are both blind to them, what the underground market pays for a live corporate session, and the four controls that actually reduce the surface.

Read it here: Phishing-as-a-Service (PhaaS): Your session is for sale

4

Solid write-up, and an important point a lot of incident playbooks still get wrong: a password reset revokes the credential, not the session. If an attacker holds a live token (or a stolen refresh token, as in the AiTM and phishing-as-a-service cases you are describing), forcing a reset does nothing until you also invalidate active sessions.

From a disclosure angle this matters two ways:

  1. If you are reporting this class of issue, frame the remediation as “revoke sessions and rotate tokens,” not just “reset password.” Reports that name the actual fix land better with vendors and get closed faster.

  2. If you are a vendor receiving one, the tell that your response is complete is that existing sessions and refresh tokens are dead, conditional access re-evaluates, and any OAuth grants the attacker created are pulled. A reset alone leaves the door open.

Thanks for posting it here.