Was the sender spoofed or compromised?
Always the first question. The email, subject "Requesting Reviewing Document Via Adobe Cloud," came from a real person at a peer organization we had worked with before. If the account was spoofed, it is an external problem. If it was compromised, someone is sitting in that mailbox right now sending phishing to the entire contact list.
The headers told the whole story:
- Message-ID ended in
@mail.yahoo.com. The email originated from real Yahoo infrastructure, not a random SMTP relay. X-Mailer: WebService/1.1.25380 YMailNorrin. Yahoo Mail web client. Someone logged into this account through a browser and hit send.- DKIM signature signed by
yahoo.comand valid. This is the key detail. A spoofed message would fail DKIM or be signed by a different domain. A valid Yahoo signature means Yahoo authenticated the sender. - MX records for the sender's domain pointed to
mx-biz.mail.am0.yahoodns.net, Yahoo Small Business hosting. The domain's mail is Yahoo and the signature is Yahoo. Everything is consistent.
Verdict: compromised, not spoofed. The attacker has this person's credentials and sent from their actual Yahoo-hosted mailbox. DKIM passed because the email genuinely came from where it claims.
The email gateway scored it at -0.82 against a kill threshold of 3.0. DKIM passed. SPF passed. The only flag was a missing To: header, which added +1.21, nowhere near enough. The gateway was never going to catch this because, technically, it is a legitimate email from a legitimate mailbox. It just happens to be sent by an attacker.
The payload
The link went through ctrk.klclick3[.]com, a Klaviyo email-marketing tracking link. Klaviyo is a legitimate platform; the attacker was abusing it for redirect infrastructure. It redirected to dccyop[.]org/[redacted], which served ScreenConnect.ClientSetup.msi, a 16.7 MB installer.
The user who said it "wasn't compatible with Windows" almost certainly hit a SmartScreen warning or a browser download block. That warning did its job.
Sandbox analysis
Sandbox score 8/10. A legitimate ScreenConnect installer, weaponized for unauthorized access:
- C2 relay:
instance-x7bxki-relay.screenconnect[.]comresolving to15.235.110.89(OVH Canada) - Session ID
c74a4df9-a1ae-422f-8ab0-a017da1ee909hardcoded in the installer config - Credential-provider DLL and authentication-package DLL installed, hooking the Windows credential pipeline
- 64 privilege-escalation attempts: SeDebugPrivilege, SeTcbPrivilege and more
- 37+ COM-hijacking registry modifications
This is the RMM-abuse pattern that is everywhere right now. The attacker does not write custom malware. They configure a ScreenConnect instance, bake the connection details into the MSI, and get persistent remote access through a signed, legitimate management tool. It installs as a service, survives reboots, and looks like normal IT software to anyone not specifically hunting unauthorized RMM.
Endpoint verification
Two machines received the email. I pulled endpoint trajectory data for both via the API and checked for ScreenConnect artifacts: files, services, registry keys, connections to the relay. Both clean. One user downloaded the MSI but never ran it. The other never clicked.
No installation on either machine. SmartScreen and user caution did the job.
The abuse reporting chain
This is where a lot of IR stops short. We confirmed no compromise on our end, but the attacker's infrastructure is still live. Every hour that relay stays up, more organizations get the same MSI. So I spent about ten minutes filing reports:
- ConnectWise: the weaponized relay instance with its session ID. ConnectWise has an abuse process and can disable the instance remotely.
- OVH: the C2 server IP, with full context.
- APWG: full IOC report to
[email protected]. - Klaviyo: the abused tracking link, to
[email protected]. - The compromised user's organization: contacted directly so they know the account is actively sending phishing.
And then there was Yahoo. Yahoo's abuse reporting is broken. The mailbox is compromised and actively phishing. The online abuse form is non-functional. [email protected] bounced with 554 mailbox not found. One of the largest mail providers in the world and you cannot report a compromised account to them. The attacker keeps sending until the owner notices or Yahoo's automation catches on. I documented the failed attempts and moved on.
Key takeaways
DKIM tells you compromised vs. spoofed. Valid signature, signing domain matching the sender's mail infrastructure: someone has the credentials. Failed or foreign-domain signature: spoofed. The distinction changes your response, because compromised means the sender's organization needs to hear from you immediately.
Gateways cannot catch compromised-account phishing. Scored at -0.82, DKIM and SPF passing. User awareness is the only layer left.
RMM abuse is the dominant delivery method. ScreenConnect, AnyDesk, Action1: signed, trusted, blends in. If you are not explicitly blocking unauthorized RMM tools, you are relying on users not to run the installer.
Report upstream. ConnectWise can disable the relay. OVH can null-route the IP. Klaviyo can kill the redirect. Ten minutes, and it disrupts the tooling for everyone downstream of you.
IOCs
| Type | Value |
|---|---|
| Redirect | ctrk.klclick3[.]com (Klaviyo, abused) |
| Payload host | dccyop[.]org |
| C2 relay | instance-x7bxki-relay.screenconnect[.]com |
| C2 IP | 15.235.110.89 (OVH Canada) |
| SHA-256 | 1BE180E92DC8F61434CA170203F16DC1CDE5B3AD26FB80A2096C48F04070F9B2 |
| Sender | [compromised mailbox at a peer organization] |