ClickFix Infostealers Are Draining Microsoft 365 Logins: What Financial Institutions Do Now

An employee opens what looks like a routine page or document. It asks them to press a couple of keys and paste a short command to prove they are not a bot, or to fix a display error. They do it. Nothing seems to happen. There is no download prompt, no antivirus warning, no obvious sign anything went wrong. Within minutes, an attacker is signed into that employee's Microsoft 365 account, reading email, opening files in OneDrive, and lining up the next move.

That pattern is called ClickFix, and it is one of the more effective techniques Microsoft's threat researchers are tracking right now. Microsoft's Defender Experts team observed increased activity from a specific information-stealing malware, ACR Stealer, between late April 2026 and mid-June 2026. The lure does the hard part for the attacker. The employee runs the command themselves, which means no software vulnerability is being exploited at the entry point and, just as important, there is no single security patch that closes it the way one closes a CVE.

For banks, credit unions, and mortgage companies, that last point changes how you have to think about this. You cannot patch your way out of an attack whose entry point is a person following instructions. What stops it is detection and response: catching the malicious behavior on the endpoint, tying it to the identity signals in Microsoft Entra ID, and having someone investigate before a stolen login becomes a fraudulent wire. That is the operating model ABT runs for financial institutions as Guardian MxDR, and it is the honest answer to a threat with no CVE attached.

A Stolen Login Is a Working Login

The reason ClickFix and ACR Stealer belong on your radar is not the malware itself. It is what the malware walks away with. ACR Stealer is an information-stealing malware family, reportedly offered through a malware-as-a-service model and associated with the rebranding of an earlier stealer called Amatera. Once it runs, it goes after the browser: stored credentials, session cookies, and authentication tokens, decrypted straight out of Chromium-based browsers like Google Chrome and Microsoft Edge using the same Windows routines the browser itself relies on to protect them.

Here is why that matters more than a stolen password. A password is a claim you still have to prove. A stolen session token is proof you already made. When the malware lifts the authentication token for a browser session your employee is signed into, the attacker can replay that session without knowing the password and, in many cases, without triggering a fresh multifactor prompt. The login is not something they have to break in to. It is something they inherit, already working.

ACR Stealer does not stop at credentials. Microsoft states that it also collects PDFs and Microsoft 365 documents, including data stored in enterprise-synchronized directories such as OneDrive and SharePoint. For a user signed into Microsoft 365 in that browser, the stolen browser session effectively is their Microsoft 365 session. The attacker gets the keys and a copy of what is behind the door in the same motion.

A working Microsoft 365 login is rarely the attacker's real goal. It is the doorway. From inside a genuine mailbox, the next steps are quiet and familiar: read the recent threads, learn how the institution talks about wire instructions and closing payoffs, then send a message that looks exactly like it belongs there.

ClickFix: An Attack With No Vulnerability to Patch

It helps to separate two things that get blurred together. ClickFix is the social-engineering technique, the "paste this to prove you are human" trick that gets an employee to run a command. ACR Stealer is the malware that command ends up running. The technique is the delivery; the malware is the payload. Microsoft documented two observed intrusion chains in this campaign, and both of them start the same way, with a ClickFix lure that convinces the user to execute the first command themselves.

This is the same shape as other identity-first attacks, where the target is not a server but a person. It sits right next to techniques like device code phishing, where an attacker turns a legitimate Microsoft 365 sign-in flow into a foothold. The common thread is that the human, not an unpatched system, is the way in.

That is what makes the "just patch it" reflex fail here. There is no exploited vulnerability at the entry point, so there is no CVE to track and no update to install that closes it. A fully patched, up-to-date machine is still exposed the moment an employee pastes the attacker's command. Patching stays essential for everything else, but it is not the control that stops this technique.

Both intrusion chains Microsoft observed begin with a ClickFix lure. One leaves disk artifacts; the other runs largely in memory. Both end at the same stolen Microsoft 365 session.

The two chains diverge in how much they leave behind, and that difference is the reason a single antivirus scan is not enough. The first chain is disk-based. It pulls a DLL from a WebDAV share, drops a ZIP-packaged payload into the user's local temp folder, runs a bundled Python runtime through pythonw.exe, and sets up persistence with a hidden scheduled task disguised as a legitimate software update. A subset of this chain even resolves its command-and-control through public blockchain endpoints, a technique Microsoft calls EtherHiding.

The second chain is the quiet one. Rather than dropping an executable, it hides its real payload inside a JPEG image, then decrypts and runs it in memory as reflective shellcode. It is near fully fileless: it still touches disk, a carrier image and some script content, but it leaves almost nothing an executable-signature scan would flag. One chain buries its artifacts behind obfuscated, randomly named paths; the other keeps its footprint to a minimum. Either way, the thing you most want to catch is the behavior, not a file.

Why Sign-In MFA and Signature Antivirus Both Miss It

Two controls most financial institutions already trust get quietly stepped around here, and it is worth being precise about why. Start with multifactor authentication. MFA is an identity control. It checks who is signing in, at the moment of sign-in. But ACR Stealer does not sign in. It steals the authentication token from a session that already passed MFA, then replays it. From the service's point of view, the session was already approved, so there is often nothing new to challenge.

That is the same weakness attackers lean on in adversary-in-the-middle phishing, where the session token is captured after the multifactor check clears. Token theft and token replay turn a one-time approval into standing access.

None of this makes MFA optional. It makes the kind of MFA, and what happens after sign-in, matter more. Moving toward phishing-resistant multifactor authentication raises the cost of stealing that first factor, and evaluating a session continuously, not just at the door, is what flags a token being used from the wrong place.

Signature antivirus has the same problem from the other direction. It is built to recognize known-bad files. The first ACR Stealer chain hides its files behind randomly named, GUID-based paths and a legitimate-looking scheduled task. The second chain keeps its disk footprint so small, a carrier image and some script, that there is little for a file scanner to recognize. A scanner that relies only on known signatures can miss both of these. What actually surfaces this is behavior: a browser's stored data being read by another process, a scripting host reaching out to a low-reputation domain, a token showing up in a session from an unexpected location.

Microsoft's own recommendations reflect exactly that. The mitigations it published are not a single toggle. They span endpoint controls and identity controls, and they only work if someone is configuring them, watching them, and acting on what they surface.

The Defense Is an Operating Model, Not a Product

If the recommendations span endpoint and identity, and the whole point is tying them together and acting fast, then the thing you actually need is not one more tool to buy. It is an operating model: someone hardening the tenant, watching the signals across both families, and responding when something looks wrong at three in the morning. That is what managed detection and response means. Some institutions build it in-house; many banks, credit unions, and mortgage companies do not have a round-the-clock security team and bring in a partner for it, and it is what ABT runs for financial institutions as Guardian MxDR.

Guardian MxDR sits across the Microsoft security stack ABT already manages in your Microsoft 365 tenant. On the endpoint side, that means Microsoft Defender configured the way Microsoft recommends and kept there: endpoint detection and response in block mode, cloud-delivered protection on, application control and attack surface reduction rules restricting the scripting and living-off-the-land tools these chains lean on. On the identity side, it means Microsoft Entra ID Conditional Access enforced and monitored, so a session that shows up in the wrong place or behaves oddly gets challenged or cut off instead of trusted. Behind both sits a security operations team that investigates the fileless, in-memory activity Microsoft describes, rather than waiting on a file signature these chains are built to slip past.

That cross-signal view is where a Microsoft partner who works the whole sector earns its keep. ABT is a Tier 1 Microsoft Cloud Solution Provider that runs this operating model for more than 750 financial institutions, so the account-takeover and token-theft patterns that surface at one bank, credit union, or mortgage company shape how the next tenant is watched. A generalist help desk that touches Microsoft 365 now and then does not get that view, and the view is what turns a stray sign-in into an investigation before it turns into a wire.

Conditional Access is central to that identity layer, and Microsoft has been tightening how it is enforced. Recent changes to Conditional Access enforcement close gaps that stolen sessions used to slip through, which is exactly the kind of configuration ABT manages and monitors on an ongoing basis rather than setting once and forgetting.

No single layer stops a stolen session. Guardian MxDR ties Microsoft Defender endpoint signals to Microsoft Entra ID identity signals and puts a security operations team on top.

What Financial Institutions Do Now

You do not have to wait for a full engagement to start closing the gaps this attack uses. Some of it is configuration you can verify this week; some of it is the operating discipline that keeps the configuration from drifting. Here is the short list, mapped to what Microsoft recommends.

• Put endpoint detection and response in block mode. Cloud-delivered protection, automated investigation and remediation, and tamper protection should all be on, not left in audit-only.
• Restrict the tools these chains abuse. Use application control and attack surface reduction rules to limit how PowerShell, Python, mshta.exe, and rundll32.exe run, and turn on PowerShell script-block and module logging.
• Enforce Conditional Access and reduce browser-stored credentials. Tighten Microsoft Entra ID Conditional Access and move people off saving passwords in the browser, which cuts what the stealer can pull from the credential store.
• Filter the web at the endpoint. Block low-reputation and newly observed domains so the lure and its command-and-control have fewer places to land.
• Watch continuously, and staff the response. Configuration drifts and alerts arrive at night. Someone has to be watching the endpoint and identity signals together and ready to act on them.

The last item is the one institutions underestimate. The controls are necessary, but they are not self-driving. Without someone watching, the gap between compromise and discovery is measured in days, and days are all business email compromise needs.

What Your Examiner Expects You to Have

None of this is only a security question. It is a supervisory one, and the specific rule depends on what kind of institution you are. This is where "banks, credit unions, and mortgage companies" stops being a courtesy phrase and starts mattering, because each answers to a different regulator, and mixing them up on an exam is its own problem.

Independent, non-depository mortgage companies are generally covered by the FTC Safeguards Rule, 16 CFR Part 314. It calls for multifactor authentication (Section 314.4(c)(5)), monitoring and logging of authorized-user activity to detect unauthorized access (Section 314.4(c)(8)), regular testing of safeguards including continuous monitoring or periodic penetration testing and vulnerability assessments (Section 314.4(d)), and a written incident response plan (Section 314.4(h)). A stolen-token account takeover touches all four.

Banks are not under the FTC Safeguards Rule. They answer to the interagency Information Security Standards that implement Section 501(b) of the Gramm-Leach-Bliley Act, published by the OCC (12 CFR Part 30, Appendix B), the FDIC (12 CFR Part 364, Appendix B), and the Federal Reserve (12 CFR Part 208, Appendix D-2). Federally insured credit unions answer to the NCUA under 12 CFR Part 748, Appendix A. Different citations, same expectation: protect customer and member information, detect unauthorized access, and be able to respond.

For the banks and credit unions supervised by FFIEC member agencies, the FFIEC's guidance on Authentication and Access to Financial Institution Services and Systems, issued in 2021, sits on top of those rules. It is risk-based supervisory guidance, not an absolute mandate. It recommends layered security and authentication strong enough for the risk, often multifactor, plus monitoring for credential theft and account takeover, and it recognizes controls of equivalent strength. Non-depository mortgage companies answer to the FTC rather than the FFIEC, but the same risk, a stolen working session replayed, is exactly what all of these regimes are built to make you detect and answer for.

The through-line is simple. Your examiner is not going to ask whether you patched a CVE that does not exist. They are going to ask whether you can detect unauthorized access, whether you monitor authorized-user activity, and whether you have a plan for the day a login turns out to be in the wrong hands. No regulation names a specific product, and how you get to yes is your call. Guardian MxDR is one way to get there, giving you the continuous detection, response, and evidence those questions assume.

Frequently Asked Questions