What Is Credential Harvesting?

A user types a password into a page that looks like the company login, and nothing on screen says anything went wrong. The attacker now has the login, and in many cases the MFA-approved session that came with it. That is credential harvesting, and this post covers how it is done today, why MFA alone does not stop it, and what to change first.

What Credential Harvesting Means

Credential harvesting is the collection of usernames, passwords, MFA codes and session tokens from people and devices, at scale, for later use or sale. The word "harvesting" is the point. The attacker is not guessing. They set up a machine that collects logins from whoever lands on it, then sort the crop by value.

It is different from credential stuffing. Stuffing replays already-stolen passwords against other sites to find reuse. Harvesting is the step before that: it is how the passwords get stolen in the first place. The output of one feeds the other.

The crop has a market. Harvested Microsoft 365 or Google Workspace logins are sold, traded and used for business email compromise, invoice fraud and as a foothold for ransomware. The most common passwords get cracked; the good ones get harvested.

The Four Ways Logins Get Harvested

Fake login pages are the oldest route. A phishing email or a SharePoint share notification leads to a copy of the sign-in page, the user types the password, and the page either errors out or forwards them to the real site. Kits sold on criminal forums make these pages in minutes, with the brand, the redirect and the exfiltration already wired.

Adversary-in-the-middle (AiTM) kits are the modern version. The phishing page is a live proxy. It relays every request to the real login service and every response back, so the user sees the real MFA prompt and approves it. The proxy captures the password and the session cookie that the service issues after MFA. Microsoft's own description of the technique says the phishing page "practically functions as an AiTM agent, intercepting the whole authentication process."

Infostealers skip the login page. They are malware that reads saved passwords, session cookies and autofill data straight out of the browser, then ships the bundle to the operator. Lumma, the stealer Microsoft disrupted in May 2025, spread through fake CAPTCHA prompts, poisoned search ads and pirated software. Microsoft counted more than 394,000 Windows computers infected between March 16 and May 16, 2025, before it took down about 2,300 of Lumma's domains in May.

Device-code and consent phishing round it out. The user is asked to enter a short code on a real Microsoft page, or to approve an app's permissions, and the token lands with the attacker. No fake page, no password typed.

Why MFA Alone Does Not Stop It

MFA stops the oldest route. A harvested password is useless if the attacker cannot answer the second factor. That is why phishing moved to AiTM.

An AiTM proxy does not break MFA. The user completes MFA for real, on the real service, through the proxy. What the attacker takes is the session cookie issued afterwards. Microsoft is explicit about it: "this is not a vulnerability in MFA; since AiTM phishing steals the session cookie, the attacker gets authenticated to a session on the user's behalf, regardless of the sign-in method the latter uses." Number matching, push notifications and one-time codes all get relayed the same way.

This thread from r/sysadmin is the case that keeps coming up: an account compromised with number-matching MFA in place and no obvious phishing email in the mail flow. The replies land on token theft, and on the fact that a proxy kit like Evilginx is not stopped by number matching.

Infostealers are worse for MFA because they take the cookie after the fact. The user signed in properly on Monday. The stealer read the cookie on Wednesday. The attacker replays it on Thursday, with no prompt for anyone to notice.

What Happens After the Harvest

The first move is usually quiet. The attacker signs in with the cookie, searches the mailbox for words like invoice, payment and wire, and creates an inbox rule that moves replies from finance into an obscure folder. Microsoft's own Defender playbook for stolen-cookie alerts tells responders to look for exactly that: new inbox rules, mailbox searches and sign-ins from a second country during the same session.

Then comes the use. Business email compromise, a fake invoice sent from the real mailbox, a password reset on the payroll portal, or the login sold on to a ransomware crew. Verizon's 2026 Data Breach Investigations Report puts exploited software vulnerabilities at 31% of breaches, now ahead of stolen passwords as the top way in. Stolen logins are still the door that needs no exploit.

For an MSP the harvest rarely stays in one tenant. A compromised technician account, or a client account with delegated access, is the fastest path to every tenant that identity can reach. That is the reason email security best practices and identity hardening belong in the same project.

Defences That Match the Attack

Start with the factor. CISA's phishing-resistant MFA guidance ranks the forms from strongest to weakest: FIDO2 or WebAuthn keys and certificate-based authentication at the top, app codes and push with number matching in the middle, SMS and voice at the bottom. Microsoft's built-in "phishing-resistant MFA strength" in Entra Conditional Access allows three methods: FIDO2 security keys, Windows Hello for Business or a platform credential, and certificate-based authentication. Passkeys in Microsoft Authenticator count, so this no longer means buying a hardware key for every user.

Phishing-resistant MFA beats AiTM because the credential is bound to the real site's origin. The proxy sits on a different domain, so the key refuses to sign for it. No relay, no cookie.

Then bind the session to the device. Conditional Access policies that require a compliant or registered device stop a cookie replayed from the attacker's machine. Entra's token protection goes further for supported apps: it binds the refresh token to the device cryptographically, so a stolen token "can't be used from another device." Continuous access evaluation shortens how long a stolen access token stays useful, from the default one hour to near real time for apps that support it.

This r/msp thread from March 2026 asks the practical question: how to roll phishing-resistant MFA to average clients without hardware keys. The replies point at passkeys in Authenticator, continuous access evaluation, and app protection policies with a temporary access pass for enrollment.

Infostealers need endpoint controls, not identity controls. Block unsigned executables and scripts, keep browsers from saving passwords where a manager does the job, and treat "paste this command to prove you're human" as the malware delivery it is. An identity and access platform handles the token side; the stealer side is patching, application control and a password manager.

Training still has a place, aimed at the new tells. A security awareness program that only teaches "check the sender" misses the fake CAPTCHA, the device-code prompt and the SharePoint share from a real, compromised colleague. OpenFrame can run a script across a client's devices to list browser password stores and startup entries and collect the output, which is a quick way to see where saved passwords still live.

The First Hour After a Harvest

Order matters, because a password reset alone leaves the stolen session alive. Microsoft's emergency revocation guidance for Entra is the sequence to follow: disable the account, reset the password (twice in a hybrid environment, to close pass-the-hash), then revoke the refresh tokens with Revoke-MgUserSignInSession so every app has to sign in again. Existing access tokens die when they expire, which by default is within an hour.

Then look for what the attacker left. Inbox rules, mail forwarding, new MFA methods registered on the account, OAuth apps granted consent, and sign-ins from the same session ID in a second country. Block the sender domain and the phishing URL at the mail gateway and the DNS filter. If the login was a technician's, treat every tenant it could reach as in scope until the logs say otherwise.

IBM Technology's walkthrough of the five ways passwords get stolen is a clear ten minutes for anyone new to the terms, and it covers the harvesting routes above in order:

Write the sequence down before it is needed. An incident response plan for a small team is mostly this: who revokes, who resets, who reads the logs, and in what order.

The Short Version

Credential harvesting is the industrial collection of logins and sessions, through fake pages, AiTM proxies, infostealers and token phishing. Standard MFA stops the first route only. Phishing-resistant MFA, device-bound sessions and endpoint control stop the rest, and a written revoke-reset-hunt sequence limits the damage when one gets through. Start with passkeys for the accounts that matter most, then read the post on the passwords attackers try first.

FAQ

What is the difference between credential harvesting and phishing?

Phishing is the lure: the email, text or share notification that gets a person to act. Credential harvesting is one thing the lure is for, the collection of the login or session that follows. Phishing can also deliver malware or a fake invoice; harvesting can also happen with no lure at all, through an infostealer.

Does MFA stop credential harvesting?

It stops the fake-page route, where only a password is taken. It does not stop adversary-in-the-middle proxies or infostealers, because both take the session cookie issued after MFA succeeds. Phishing-resistant methods such as FIDO2 keys and passkeys do stop the proxy, because the credential only works on the real site's domain.

How do I know if an account's credentials were harvested?

Look for a sign-in from a new country or ISP within the same session as a legitimate one, new inbox rules or forwarding, a newly registered MFA method, OAuth consents the user does not recognise, and mailbox searches for payment terms. Microsoft Defender raises "Stolen session cookie was used" and "Authentication request from AiTM-related phishing page" alerts for the proxy case.

What should I do first after credentials are harvested?

Disable the account, reset the password, then revoke sessions so the stolen cookie and refresh tokens stop working. A reset alone does not end the session. After that, remove inbox rules and consents the attacker added, block the phishing domain, and check any other tenant or system the account could reach.