AI Weekly Malaysia

Microsoft Security Research reported a phishing campaign, detected in July 2026, that delivers a digitally signed MSP360 RMM v2.5.0.67 installer disguised as meeting invites, PDF readers, software updates, and e-card/RSVP lures (e.g. VIP_ECARD_INVITATION_rmm_v2.5.0.67_oid[redacted].exe, SSA.GOV_STATEMENT_rmm_v2.5.0.67_oid[redacted].exe). The installer relaunches itself through the Windows UAC elevation flow, drops DLLs, registers RMM.Agent.exe and RMM.Agent.Launcher.exe as Windows services with Registry autorun entries, and opens inbound UDP port 48678 in Windows Firewall. It then uses MSP360 to run PowerShell that installs a ConnectWise ScreenConnect client as a second, redundant remote-access channel for tool delivery and credential access. Payloads were staged on both attacker infrastructure and legitimate services including Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase. Microsoft did not attribute the activity to any known threat actor.

Why: The thing that got past defences was a valid vendor signature on a legitimate MSP360 binary, so 'it's signed' is not a trust decision on its own — the detectable signal here is the lure filename pattern (_rmm_v2.5.0.67_oid...) and the combination of an RMM service plus a ScreenConnect install on the same host. If you don't deploy MSP360 RMM anywhere, you can alert or block on RMM.Agent.exe / RMM.Agent.Launcher.exe services, autorun registry entries, and outbound UDP 48678 rather than waiting for an AV signature. If you run any file-hosting or storage product (S3, R2, Dropbox, GitLab, Supabase were all used as staging), treat abuse-reporting and takedown for hosted installers as an operational cost, not an edge case. There is no Malaysia-specific angle in this report, so treat it as a generic endpoint-detection change.