The Invoice That Wasn’t
It was a normal Monday morning. Sarah, who works in finance, opened her inbox and saw an email from one of the company’s regular suppliers.
The subject line: “Outstanding Invoice – Please Review”.
It looked genuine. The logo was there, the tone was professional, and the sender’s name matched someone she knew. In the rush to get through her emails, Sarah clicked the link.
A familiar Microsoft login page appeared. She typed her username and password. Her phone buzzed with an MFA prompt. Without thinking, she approved it — just like she always did.
The page then showed an error: “Document not found.”
Sarah shrugged. Maybe the supplier had made a mistake. She moved on with her day.
Behind the scenes, something else was happening.
Sarah hadn’t logged into Microsoft 365 at all. She had entered her details into a fake page, built by hackers using a phishing kit called Salty2FA. As soon as she approved her MFA prompt, the hackers were inside the company’s account — with full access to emails, documents, and contacts.
They quietly:
- Set rules to forward sensitive emails out of the company.
- Sent new phishing emails to Sarah’s colleagues, using her real account.
- Looked through OneDrive and SharePoint for contracts and invoices.
Nobody noticed right away, because everything looked like normal, approved logins.
The Lesson for Us
- MFA is strong, but not foolproof. If attackers trick you into approving a login, they can still get in.
- Always check the link before you enter your credentials. A single letter difference in a web address can mean the page is fake.
- Pause before approving an MFA prompt. Ask yourself: Am I really logging in right now? If not, deny the request and report it.
- When in doubt, don’t click. If something looks urgent, unexpected, or slightly off, verify with the sender by phone or another trusted channel.
✅ Key takeaway: Security isn’t just about technology — it depends on our daily choices. Taking a moment to stop and think before clicking or approving can be the difference between a normal workday and a serious breach.
How the hacker thinks – A Regular Company, a Regular Setup… and Salty2FA
1. The Setup
The hackers has a company in the target point. With his company reputation score list he sees if passwords and o365 credentials in the pass were pawned. He get a company user target score seeing that they have bad habits in private life. He is in a game challenge with other hackers having positive hits. For the game they need to hit 50 mid-sized professional services firms. Like many companies, they’ve migrated fully to Microsoft 365 for email, collaboration, and document storage. They’re following baseline security:
- MFA is enabled (users approve via mobile push or enter a six-digit OTP).
- IT enforces password complexity, but there’s no conditional access or zero trust model — anyone with the right credentials and MFA code can get in, from any device, any location.
- Legacy protocols like IMAP and SMTP are technically still enabled for compatibility.
The hacker sees many statement on social media and leaked security policies showing management’s point of view, this looks “secure enough.” After all, MFA is there.
2. The Lure
One Monday morning the hacker is sending a mail to a employee in finance that looks almost perfect:
- It’s from a supplier they know.
- It references an unpaid invoice.
- There’s a link to a “secure portal” to download the PDF.
The hacker is counting on the high work pressure in the company, knowing that in 50% of the attempts the employee will click. He prepared a screen and page that looks identical to the Microsoft 365 login screen — even the domain name looks convincing. They don’t notice the subtle misspelling.
3. Enter Salty2FA
Unbeknownst to the user, they are not on Microsoft’s servers at all. They are on a Salty2FA phishing proxy. This malicious kit works as a “man-in-the-middle”:
- When the employee types their username and password, Salty2FA forwards it instantly to the real Microsoft login page.
- When the MFA push or OTP arrives on the employee’s phone, they approve it — thinking it’s a normal login.
- Salty2FA relays the MFA code in real time and gains full access to Microsoft 365.
From the employee’s perspective, nothing seems wrong. They see the expected error message: “Document not found.” They assume the supplier link was broken and move on with their day.
4. The Hacker’s Leverage
Now the attacker has an active O365 session token — not just the password.
- They immediately set up inbox rules to silently forward sensitive emails.
- They send internal phishing emails from the compromised account to HR and Sales. Because these come from a trusted sender, colleagues click more easily.
- They register a malicious OAuth app, granting themselves long-term API access even if the password changes.
- They exfiltrate sensitive documents from OneDrive and SharePoint.
The IT team sees only “successful logins with MFA” — so no red flags are raised.
5. Human Behavior: The Weakest Link
Why did this work? Because humans behave predictably:
- Employees trust familiar-looking emails.
- They click links under time pressure.
- They approve MFA prompts automatically, without thinking.
- They believe “MFA = safe” and don’t suspect sophisticated phishing.
The attacker exploits these habits — not just technology.
6. Why a Non–Zero Trust Setup Fails
The company’s MFA was binary: if the code is entered, access is granted — no context checks. With no conditional access in place:
- Logins from strange geographies (e.g., Eastern Europe at 3 AM) weren’t blocked.
- Access from unmanaged devices was allowed.
- Session lifetimes were long, so stolen tokens remained valid for days.
In short, their setup assumed: “If MFA succeeds, the user is genuine.” Salty2FA exploits exactly this assumption.
7. The Fallout
By the time IT notices suspicious forwarding rules, weeks of sensitive data are gone. The attackers have harvested invoices, client contact lists, and internal project details — enough to launch targeted fraud or ransomware campaigns.
The company had MFA, but without zero trust principles (phishing-resistant MFA, device and location controls, token protections), it wasn’t enough.
Takeaway
Salty2FA and similar AiTM phishing kits thrive on companies that think “MFA alone is enough.” Attackers know that human behavior (clicking, approving) combined with a non-zero trust MFA setup gives them a wide-open door.
The only real countermeasures:
- Adopt phishing-resistant MFA (FIDO2 / passkeys).
- Enforce conditional access and device compliance.
- Monitor for anomalies like token replay, new OAuth apps, and impossible travel.
- Train employees to pause and verify MFA prompts.
Salty2FA (a recent Phishing-as-a-Service kit / AiTM phishing kit) is designed to intercept MFA flows, so themost effective countermeasure is to move away from OTP/push methods that can be relayed and to require phishing-resistant authentication (FIDO2 / WebAuthn / hardware keys) combined with conditional access, email protections and endpoint controls. ANY.RUN+1
What Salty2FA does (very short)
Salty2FA is a commodity phishing kit that presents fake login pages, captures creds + 2FA responses (or relays push/OTP) and then replays or hijacks sessions — i.e., an adversary-in-the-middle (AiTM) MFA bypass. Treat it like other modern AiTM phishing kits: Tycoon, EvilProxy, etc. ANY.RUN+1
High-impact countermeasures (ordered)
Require phishing-resistant MFA (FIDO2 / WebAuthn / hardware keys).
- FIDO2 / passkeys and platform/hardware authenticators are currently the most practical, widely-recommended defense against AiTM phishing. CISA, FIDO Alliance and Microsoft all recommend moving to phishing-resistant authenticators where possible.
Enforce “phishing-resistant” authentication for sensitive accounts via Conditional Access / auth policies.
- For Microsoft 365/Azure AD: require the built-in phishing-resistant authentication strength for admin and high-risk groups; block weaker fallbacks for those accounts. (Microsoft has guidance and controls for this.)
Disable or tightly restrict legacy/fallback auth paths (basic auth, SMS/voice fallback, OAuth app consent where not needed).
- Many AiTM kits exploit fallback methods. Remove or restrict SMS/OTP where you can, or reserve them only as last resort with compensating controls. Expert Insights
Harden endpoint posture & device signals (require compliant devices, EDR, disk encryption).
- Conditional access that requires device health reduces the attacker surface (harder to intercept sessions from unmanaged endpoints). Microsoft Learn
Tighten session security & token protections
- Reduce token lifetime for risky apps, enforce continuous session checks, and use risk-based conditional access (prevent long-lived session replay). Microsoft Learn
Detection & monitoring
- Monitor for anomalous logins, impossible travel, new OAuth consents, and unusual token/session replays; forward such events to SIEM/SOAR. Rapid detection reduces impact. Expert Insights
User controls to blunt push/consent attacks
- Enable number-matching for push approvals, limit excessive push prompts (MFA fatigue), and educate users to reject unexpected prompts. Expert Insights
Practical checklist you can hand to your MS365 / Identity admin
- Enable phishing-resistant auth for all admins and high-value users (FIDO2 only). Microsoft Learn
- Block legacy auth and disable SMS/voice OTP where possible. Expert Insights
- Require device compliance for access to sensitive resources. Microsoft Learn
- Turn on ATP/URL protections, configure Safe Links, and consider browser isolation for externals. CSO Online+1
- Audit and block suspicious OAuth app registrations; restrict admin consent. Proofpoint
- Roll out hardware security keys / passkeys with a staged user onboarding plan (pilot → domain roll-out). Yubico Support
Limitations & tradeoffs
- FIDO2 adoption requires user onboarding and hardware/platform support; you may need an interim mitigation strategy (conditional access + restricted fallbacks). FIDO Alliance
- Some services or browsers may fall back to weaker methods; ensure you explicitly block or require extra checks when fallback occurs. Proofpoint research shows attackers can try to force fallbacks. TechRadar
Quick mitigation if you can’t immediately deploy FIDO2
- Immediately disable legacy auth + SMS where feasible.
- Force reauth and shorten session lifetimes for privileged roles.
- Tighten conditional access (block risky locations, require compliant device).
- Apply advanced email filtering, and run a focused phishing awareness campaign emphasizing “don’t accept unexpected prompts”.
