Why do compromised accounts, trusted hosting services, and AiTM proxies make credential theft so hard to stop?

Why the attack keeps working even after a user is cautious

Compromised accounts and trusted hosting services do not just make a link “look normal”, they preserve the exact trust signals defenders rely on. The email may pass domain authentication, the landing page may sit on a reputable platform, and the login flow may still look routine. That combination lowers suspicion at every checkpoint and makes simple blacklist-based blocking ineffective.

Legitimacy is the weapon. The attacker is not trying to look obviously malicious; they are trying to look operationally correct long enough to reach the credential capture step and the follow-on session theft step.

When the sender account is already trusted, the usual user heuristics fail first, then the mail security controls have less to distinguish from normal business traffic. That is why these campaigns often survive longer than commodity phishing even when basic awareness and email filtering are in place.

Why AiTM proxies defeat the old “password plus MFA” assumption

An adversary-in-the-middle proxy changes the game because it can relay the victim’s interaction in real time. If the user enters a password and completes MFA, the proxy can pass those values to the real service immediately, capture the resulting session cookie, and keep using the authenticated session after the human has closed the browser.

This is why modern credential theft is often less about stealing a static password and more about stealing the authenticated session. Once the attacker has a valid session token, many downstream controls that depend on interactive login are already bypassed.

• Phishing-resistant MFA reduces this risk, but only when the authentication method is bound to the origin and the session is not reusable outside the intended context.
• Session freshness, device checks, and step-up authentication help, but they must be paired with detection that can see anomalous sign-in patterns and token replay.
• Short-lived sessions and tighter conditional access shrink the window, but they do not remove the need to watch for relay infrastructure and impossible travel or new-device anomalies.

What practitioners should look for in the control stack

Defenders need to think in layers, because the weakness is layered. Email trust, web reputation, identity proofing, and session handling all contribute to the final outcome. If one layer only checks “was the password correct?” it will miss the more important question: “was the session established through a channel that can be relayed or stolen?”

In practice, this means prioritising controls that reduce trust in the path, not only the login event. Service abuse, proxy-based interception, and compromised sending accounts all point to the same conclusion: the attacker is exploiting legitimate infrastructure and legitimate authentication flows, so the response has to include detection of session theft, rapid account containment, and credential or token rotation when compromise is suspected.

For teams wanting a deeper control model, NHI-focused guidance on NHI security governance and lifecycle helps frame why long-lived secrets and excess trust are so hard to unwind, while the static vs dynamic secrets discussion explains why short-lived credentials are preferable when you are trying to limit replay value. The broader Top 10 NHI Issues page is also useful for understanding how overprivilege and poor lifecycle control enlarge the blast radius after theft.

Risk and Threat Considerations

These attacks are hard to stop because they preserve trust at multiple layers at once: mailbox trust, web trust, and authentication trust. The result is not only credential capture, but also token and session theft, which can turn a successful login into persistent unauthorised access even when MFA was completed.

Failure mechanism: A compromised trusted account authenticates the message, a reputable host reduces user suspicion, and an AiTM proxy relays the login in real time so the attacker can steal the resulting session and reuse it.

Impact: Defenders may see a “valid” login with no obvious malicious password failure, while the attacker quietly gains durable access that can be used for mailbox takeover, internal lateral movement, or follow-on fraud.

Practitioner Guidance

What to verify: Treat any successful login that comes through a suspicious link, unfamiliar domain, or newly seen hosting platform as a session-risk event, not just a credential event. Validate whether the session was established through a phishing-resistant method, whether the browser or device posture matches normal behaviour, and whether any cookies or tokens should be revoked.

Decision rule: If you have evidence of proxy-based interception, prioritise token revocation, session invalidation, and account containment before assuming the password alone needs changing. Password resets help, but they are insufficient if the attacker already holds a live session artifact.

Common mistake: Teams often overfocus on the login prompt and underfocus on the post-authentication session. That leaves them blind to the attacker’s real objective, which is persistence through stolen session state rather than repeated password guessing.

Practitioner takeaway: The practical defence is to make stolen credentials less useful, then make stolen sessions short-lived, bound, and observable, because the attacker succeeds when legitimacy survives all the way through to access.

Related resources from NHI Mgmt Group

• Why do legitimate cloud services and business email accounts make credential theft harder to stop?
• Why do clean-looking recipient accounts make APP fraud so hard to stop?
• Why do proxies and consumer VPNs make credential attacks harder to stop?
• How should teams reduce the risk of credential theft from compromised routers and remote access services?