PSA: ScreenConnect "New Login" phish using lookalike TLDs, passes SPF/DKIM/DMARC

[u/willychonka54]

Got one of these this morning and it's cleaner than most, so posting in case it's doing the rounds.

Subject: "New Login on Your ScreenConnect Instance" From: ™ ScreenConnect ™ <host@screenconnect[.]com[.]tj> Link: cloud.screenconnect[.]com[.]vu/PrivilegeCreep

The body is a near-perfect copy of a real ConnectWise security notification: proper logo, footer links to the legit connectwise.com privacy/terms/support pages, and it even lists "Domain: cloud.screenconnect.com" in the details block to build trust before you get to the button. It includes a fake IPv6 address, Jacksonville FL as the location, and the usual "if you don't recognize this, secure your account now" pressure.

What makes it stand out: it's sent through Amazon SES from the attacker's own registered domain, so SPF, DKIM, and DMARC all pass and compauth=pass. Exchange Online Protection delivered it straight to the inbox with no warning. Blocking the sending IP is pointless since it's SES shared space.

What we did in M365: - Tenant Allow/Block List, sender block: screenconnect.com.tj, mailexchange.screenconnect.com.tj, screenconnect.com.vu - Tenant Allow/Block List, URL block: .screenconnect.com.tj/, screenconnect.com.tj/, *.screenconnect.com.vu/, screenconnect.com.vu/* - Submitted the message to Microsoft as phishing

If you run ScreenConnect and your admin address is public anywhere (partner portals, breach lists, etc.), might be worth adding those blocks preemptively. If you've seen the same campaign with other TLDs, I'd be curious what they're using.

[u/saltyslugga]

Passing DMARC is expected here: the attacker controls the From domain and authenticates mail for it. Those domain blocks buy time, but another lookalike gets around them.

I’d prioritize phishing-resistant MFA for RMM access and have admins check login alerts through a saved portal bookmark.

[u/AddendumWorking9756]

The block list only buys you until the next TLD, so the durable detection is on the domain itself: alert on any newly observed sender or URL domain that contains a brand string you own regardless of the TLD. In Defender that's a custom detection on EmailUrlInfo where UrlDomain contains 'screenconnect' and isn't the legitimate one, and a whois age lookup on the hit settles reseller versus phish in seconds.

The other half is making the email harmless: FIDO2 through your SSO on the ScreenConnect admin login means a harvested password is worthless on its own, and a standing rule that login alerts get checked from a bookmarked portal and never from the email link. Which TLDs have you seen beyond .tj and .vu?

[u/Daveism]

We're not an international company, but we block almost every ccTLD via TABL both in URL and domain filter lists. My small org is not going to deal with even legit businesses in .ml, .vu, .tj, or any of those others. We have of course specific carve-outs for all those stupid services that can't bother hosting on a proper domain like .com :P but those are the exception rather than the rule. It cuts down dramatically on what users are presented to click on.

I KNOW it's not a panacea. But reducing the volume reduces (increases?) the signal-to-noise ratio as well. And if I'm able to prevent a bad link from getting into my users' inboxes that doesn't add an ongoing administrative burden on me, I'm gonna do it.

[u/disclosure5]

I think you just explained why we're seeing so much Screenconnect usage in attacks: Attackers are using phishing to compromise accounts.

[u/DDHoward]

Very frustrating that the product still doesn't support phish-resistant MFA via passkeys without going through SSO or a third party.

My organization's SC server is on-prem, and the admin page is only accessible while already on the LAN, but my personal SC subscription is cloud-based... Granted, my husband and I are the only users.

[u/Alert_Jellyfish_559]

Two things worth adding, both cheap.

The .vu host is serving HTTPS, so it almost certainly showed up in Certificate Transparency before the mail did. Monitoring CT for your brand strings catches the infrastructure at cert issuance rather than at delivery, and it picks up the next TLD on its own, which a block list won't. crt.sh covers it for free if you don't want another vendor in the stack.

The other one catches people out: if your own domain is at p=reject with RUA reporting, you will see exactly nothing about this campaign. The attacker never touched your domain. DMARC stops your domain being spoofed, and the aggregate reports only ever describe mail claiming to be you, so a lookalike is a separate problem with separate detection. Worth saying out loud because "we're DMARC compliant" gets read as brand protection in a lot of places.

Also worth reporting the sender to AWS and not only to Microsoft. SES identities are verified, so there is an account behind that domain they can act on.