The Party Invite That Wasn't: Anatomy of a ScreenConnect Phishing Campaign

The Hook

It arrived like dozens of other emails do every week: a friendly, informal invitation to a get-together. The subject line read something like “Dear Friends & Family, join me for a joyful gathering…” It sounded warm, personal, unremarkable. It came from someone real. Someone in the recipient’s contact list. Someone they had exchanged email with before.

That’s what made it work.

Over the past several months, our institution, like a growing number of others in higher education and beyond, has been targeted by a phishing campaign that doesn’t rely on urgency, fear, or fake invoices. It relies on something much harder to defend against: borrowed trust.

How the Attack Works

The mechanics are simple, which is exactly why they’re effective.

1. An email account gets compromised. It doesn’t matter whose: a friend, a colleague, a family member. Once an attacker has access to someone’s real inbox and contact list, they have a delivery mechanism that no spam filter is going to flag as suspicious. The sender address is legitimate. The signature looks right. The relationship is real.

2. A party invitation goes out to everyone in that contact list. The invite is polished, casual, and socially framed: a “get-together,” a birthday party, a “special occasion.” It asks the recipient to click through to see details and RSVP.

3. The RSVP link leads to a fake invitation page, hosted on attacker-controlled infrastructure, that prompts a file download disguised as the invitation itself.

4. The downloaded file is not an invitation. It’s an installer for ScreenConnect, a legitimate, widely used remote support tool that IT teams rely on every day. In the hands of an attacker, it grants full remote access to the victim’s machine: screen viewing, keyboard and mouse control, and file access, all under the guise of software nobody thinks twice about because it’s the same category of tool their own help desk might use.

5. The compromise propagates. If the victim’s email account gets compromised in the process, the cycle repeats: their contacts receive the same invitation, from what looks like a completely trustworthy source, and the campaign spreads laterally through social graphs rather than through a traditional spray-and-pray email blast.

This isn’t a hypothetical. Security researchers and multiple institutions, including other universities, have documented functionally identical campaigns since early 2026, and our own incident response teams identified and responded to several real compromises tied to this exact pattern.

Why This One Is Different

Most phishing awareness training focuses on spotting red flags: mismatched sender domains, urgent language, suspicious links, poor grammar. This campaign sidesteps nearly all of that.

• The sender is genuine.
• The relationship is genuine.
• There’s no urgency, just a friendly invite.
• The only real anomaly, if you stop to think about it, is a simple logical inconsistency: an invitation should never require you to install software to view it. No party evite, digital greeting card, or RSVP service has a legitimate reason to ask for that.

That single inconsistency was, in every case we investigated, the only tell available before the click.

What We Found

Our incident response process combined several layers of visibility (email gateway logs, endpoint detection, and network traffic analysis) to trace the campaign from initial phishing emails through to individual compromised devices. That layered approach mattered: no single control caught everything on its own, but together they let us map the full scope of the campaign rather than treating each infected device as an isolated event.

A few findings worth sharing:

• Attacker sophistication varied by device. On some compromised endpoints, we observed the attacker deploy additional tooling after gaining access: utilities designed specifically to suppress the remote-access tool’s own notification banner, hide cursor movement during remote control, and conceal the software’s presence from standard uninstall menus. In plain terms: once inside, the attacker tried to make their continued presence invisible to the user, not just to get in undetected. On other devices, our endpoint protection caught and cleaned up the malicious installation before any of that follow-on tooling could be deployed, a direct benefit of fast, automated detection limiting how much damage an attacker can do in a short window.

• Shared attacker infrastructure. By correlating network traffic across multiple compromised devices, we confirmed that several of them were communicating back to the same command-and-control infrastructure. This told us definitively that we were looking at one coordinated campaign, not a handful of unrelated, copycat incidents.

• A zero-tolerance detection policy paid off. Because this particular remote-access tool has no legitimate business justification on our organization’s devices, our policy treats any detected presence of it as a compromise, regardless of whether we can cleanly trace it back to a specific phishing email. This meant our detection wasn’t solely dependent on catching the initial phish; it caught the outcome of the compromise even in cases where the entry vector was less clear.

• Dormant compromises are a real risk. At least one affected device had not connected to our campus network in months by the time we identified the compromise, meaning it had been carrying an active persistence mechanism on whatever network it was connecting to, entirely outside our visibility. That device is blocked from reconnecting until IT confirms it’s been fully wiped and cleared. It’s a good reminder that “we haven’t seen it on our network” is not the same as “it’s not compromised.”

What We Did About It

For every confirmed compromise, our response followed a consistent playbook:

• Quarantine the phishing emails across affected mailboxes and update mail gateway filters to catch campaign variants.
• Reset credentials for affected accounts.
• Remove the unauthorized remote-access software.
• Isolate affected devices from the network during investigation.
• Re-image devices where warranted.
• Block reconnection for any device until it’s been verified clean.

What This Means for You

You don’t need to work in higher ed IT for this to be relevant. This exact pattern (compromised account, personal-sounding invite, malicious “RSVP” download) has been reported hitting individuals, businesses, and other organizations well outside our sector.

A few practical takeaways:

• Be skeptical of any invitation that asks you to install something. Legitimate evite, greeting card, or RSVP services never require a download or a login just to view an invite.
• A familiar sender is not the same as a safe sender. If an account is compromised, everything it sends will look legitimate, because it is coming from a real, trusted source. The account just isn’t under its owner’s control anymore.
• When in doubt, verify out-of-band. A quick text or call to confirm “hey, did you actually send me a party invite?” costs a few seconds and closes off this entire attack path.
• Enable multi-factor authentication and, where available, passkeys on your email accounts. Account takeover is the first domino in this entire chain. Harden that, and the rest of the attack never gets a foothold.

Social engineering campaigns like this one succeed by exploiting something fundamentally human: our willingness to trust the people we know. That’s not a vulnerability you patch with software. It’s one you address by teaching people to pause, just for a moment, before an invitation asks them to do anything more than say yes.

This writeup describes an incident at a large institution. All internal IPs have been substituted with RFC 1918 ranges and identifying details have been generalized.