IRS Phishing Surge: RMM Malware Hits 29,000 Users
With tax season ramping up, Microsoft just flagged a massive campaign targeting roughly 29,000 users with IRS-themed phishing lures. What makes this one particularly nasty is the payload: the attackers are delivering Remote Monitoring and Management (RMM) software like ScreenConnect or similar tools.
Once the user clicks the "refund" link, they get a script that drops the RMM agent. Since these are legitimate administrative tools, they often fly under the radar on environments that allow-list common admin utilities. This gives the adversary full remote control almost immediately.
I've updated our detection logic to look for RMM processes spawning from unusual parents (like the browser or email client). Here is a basic KQL query I am running in Sentinel to catch this specific behavior:
DeviceProcessEvents
| where Timestamp > ago(3d)
| where InitiatingProcessFileName in~ ("outlook.exe", "chrome.exe", "msedge.exe", "firefox.exe")
| where FileName in~ ("AnyDesk.exe", "screenconnect.windowsclient.exe", "RemoteUtilities.exe", "ConnectWise.Control.exe")
| project Timestamp, DeviceName, AccountName, FileName, InitiatingProcessFileName, ProcessCommandLine
We are considering an outright block of these specific binaries for non-admin users, but that might break legitimate IT support workflows.
How are you guys handling RMM abuse in your environments? Are you blocking these tools by default, or relying purely on behavioral heuristics?
Great catch on the parent process check. We actually started blocking the execution of unsigned RMM binaries via AppLocker, but that only goes so far with signed malware. We also added a correlation rule that triggers if an RMM process establishes a C2 connection to a non-corporate IP range within 5 minutes of execution. It’s cut down on our false positives significantly compared to just watching for the process itself.
We've moved to a strict allow-list for remote tools. If a department needs AnyDesk or ScreenConnect, they have to request a static version and we hash-allow only that specific executable in Defender. It’s a bit of overhead for the helpdesk, but it stops the "download random .exe from a phishing link" vector dead in its tracks. User awareness training is also ramped up this time of year specifically for tax-themed lures.
Allow-listing is effective, but we also focus on behavioral analytics. Since these scripts often drop the RMM binary and immediately execute it, we hunt for child processes spawned directly by common document viewers or browsers.
If you're utilizing advanced hunting, this KQL query helps identify those suspicious execution chains:
DeviceProcessEvents
| where InitiatingProcessFileName in ~("winword.exe", "excel.exe", "chrome.exe")
| where ProcessFileName contains "ScreenConnect"
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessFileName
Has anyone observed the malware attempting to disable any endpoint protection agents prior to the RMM installation?
Solid technical controls mentioned here. From an IAM standpoint, we focus heavily on the persistence phase. These scripts frequently attempt to create local accounts for backdoor access. We monitor intensely for EventID 4720 (User Account Created), specifically if it occurs shortly after a user logon.
Here is a KQL query we use to alert on this behavior:
SecurityEvent
| where EventID == 4720
| where SubjectUserName != "DWM-1" // Filter noise
| project TimeGenerated, Computer, TargetUserName
Blocking the account creation usually stops the remote control risk effectively.
Building on the behavioral analysis, we’ve had success hunting the initial payload. These campaigns often rely on obfuscated PowerShell to drop the RMM agent. You can hunt for encoded command parameters using KQL to catch the dropper before persistence kicks in.
DeviceProcessEvents
| where ProcessName =~ "powershell.exe"
| where ProcessCommandLine contains "-enc" or ProcessCommandLine contains "-encodedcommand"
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access