Your email security stack almost certainly trusts Amazon SES. It trusts Microsoft’s sending infrastructure. It trusts domains that have valid DKIM signatures, clean SPF records, and no prior reputation flags. That trust is the attack surface now, and cybersecurity teams are getting burned by assuming that legitimacy at the transport layer means safety at the content layer. Three campaigns surfaced this week that all exploit the same gap, and none of them needed to break anything to get through your perimeter.

Three Campaigns, One Exploited Assumption

Microsoft’s Defender Research team documented a multi-stage phishing campaign using code-of-conduct lures sent from attacker-controlled domains that pass full email authentication checks. The emails look like HR policy warnings, they arrive from signed domains with clean reputations, and they route through legitimate email relays. The endgame is an adversary-in-the-middle (AiTM) session token theft that sidesteps multi-factor authentication entirely. You log in, the attacker’s proxy captures your session cookie, and MFA never comes into play again.

Separately, Bleeping Computer confirmed that abuse of Amazon SES is accelerating. Attackers register AWS accounts, configure SES for sending, and fire off phishing emails that arrive with AWS’s sending reputation attached. Standard reputation filters see a known good sender. Your firewall sees nothing anomalous at the network layer. The emails land. The payload is whatever the attacker needs: credential harvesting pages, AiTM proxies, or direct malware drops.

Then there’s VENOMOUS#HELPER. Securonix tracked this campaign hitting over 80 organizations since at least April 2025. The initial phishing email is the delivery mechanism, but the actual payload drops SimpleHelp or ScreenConnect, both legitimate remote monitoring and management tools. Once those agents are installed, the attacker has persistent remote access that looks exactly like your own IT team’s remote support traffic. Threat detection tools trained on malicious signatures see nothing because the tooling is commercially signed and routinely used in enterprise environments.

These three campaigns share one architectural assumption your defenders are making: that authenticated senders and signed tools are safe. Attackers mapped that assumption and built their entire delivery chain on top of it.

Stop Trusting the Envelope

The hard reframe here is that SPF, DKIM, and DMARC are origin-verification controls, not content-safety guarantees. They tell you that an email actually came from the domain it claims to be from. They tell you nothing about whether that domain is malicious, whether the content is a lure, or whether the sending account was legitimately provisioned or purchased for three dollars on a fraud forum.

AiTM attacks break the mental model that MFA closes the authentication loop. Session token theft happens after the user authenticates successfully. Your logs will show a clean login. Your MFA vendor will show a successful push approval. The breach is already done. Incident response after AiTM compromise requires examining session context, not just authentication events.

Here’s what your team should be doing right now, regardless of which specific tools you’re running:

• Implement phishing-resistant MFA, specifically FIDO2 hardware keys or passkeys, for any role that can access email, admin consoles, or cloud tenants. TOTP and push-based MFA don’t stop AiTM.
• Enforce Conditional Access policies that bind authenticated sessions to device compliance and known IP ranges. A stolen token used from an unknown location should trigger step-up authentication or an automatic block.
• Audit every RMM tool installed in your environment against your approved software list. SimpleHelp and ScreenConnect are legitimate products, but if they’re present on systems your IT team didn’t touch, that’s an active incident.
• Configure your email platform to flag or quarantine messages from first-seen sending domains, even if they pass authentication checks. New domains sending bulk mail at odd hours warrant extra scrutiny.
• Apply strict egress filtering at the network layer. Legitimate RMM agents have known callback domains. If you see RMM-style traffic pointing to infrastructure outside your approved vendor list, that’s a threat detection signal worth acting on immediately.

Build Detection Around Behavior, Not Signatures

The reason these campaigns survive is that signature-based detection has nothing to grab onto. The emails are authenticated. The RMM agents are signed. The sending infrastructure has clean reputation scores. Security hardening against this class of attack requires shifting your detection investment toward behavioral signals.

Session anomaly detection is the most direct control against AiTM token theft. If an authenticated session originates from a new ASN, a different country, or a device that doesn’t match the one used for MFA enrollment, that session needs to be challenged or terminated. Most enterprise identity platforms support this out of the box; the problem is that teams haven’t turned it on or tuned it tightly enough to be useful.

For RMM-based persistence, the signal isn’t the tool itself. It’s the installation pattern. RMM agents installed outside of your standard provisioning workflow, without a corresponding helpdesk ticket, from a user account that doesn’t belong to IT, are an incident waiting for someone to notice. Process creation logs and software inventory telemetry will catch this if someone is actually watching.

Defense in depth means layering controls that each assume the others will fail. Your email filter will miss authenticated phishing. Your brute-force protections don’t apply to stolen session tokens. Your firewall won’t flag signed RMM traffic. The gaps are predictable. The job is building compensating controls that see what each layer misses, and making sure someone on your team is responsible for reviewing the combined picture every single day.

Attackers aren’t breaking your tools. They’re walking through the doors your tools were designed to leave open.

Sources

• Breaking the code: Multi-stage ‘code of conduct’ phishing campaign leads to AiTM token compromise (Microsoft Security Blog)
• Amazon SES increasingly abused in phishing to evade detection (Bleeping Computer)
• Phishing Campaign Hits 80+ Orgs Using SimpleHelp and ScreenConnect RMM Tools (The Hacker News)
• RMM Tools Fuel Stealthy Phishing Campaign (Dark Reading)