UAC-0050 Expands to European Finance: RMS Malware & Domain Spoofing
Just reviewed the report on UAC-0050 pivoting to a European financial institution. It’s a clear sign of escalation—moving beyond Ukrainian targets to hit entities likely supporting the war effort financially. Their TTPs involve heavy social engineering combined with RMS (Remote Management System) malware, effectively giving them hands-on-keyboard access immediately.
The core of the attack relies on spoofed domains to deliver the payload. Once the RMS malware executes, it provides full remote control, creating a significant detection challenge since the traffic mimics legitimate remote admin tools.
We've started hunting for suspicious RMM activity in our environment. Specifically, we're looking for instances where popular RMM binaries are spawned by user-land applications (like Office) rather than IT management tools:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("anydesk.exe", "supremo.exe", "screenconnect.windowsclient.exe")
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, SHA256
Additionally, we're blocking execution of unsigned binaries in user directories via PowerShell script block logging.
For those in the financial sector, are you seeing similar targeting? And how are you balancing the need for third-party remote support against this specific threat vector without breaking operations?
Solid query. We actually took this a step further and added a correlation rule for unsigned binaries. Legitimate commercial RMM tools like TeamViewer or AnyDesk are almost always signed. If the RMS malware they're using is a crack or custom build, the signature check is your fastest tripwire.
We also set up a basic PowerShell script to audit existing RMM installations:
Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*Remote*" -or $_.Name -like "*AnyDesk*" -or $_.Name -like "*TeamViewer*" } | Select-Object Name, Version
If you find an instance that isn't in your CMDB, assume compromise.
From the MSP side, this is a nightmare scenario. We rely heavily on RMMs for client support. We implemented a policy where no RMM tool can run unless it's installed from a specific software deployment GPO and strictly version-locked.
The spoofed domain angle is interesting though; we've been pushing all our clients to p=reject on DMARC, but the phishing emails still get through the filters occasionally. It really comes down to user training at that point.
Solid insights. To complement the signature checks, focusing on behavioral telemetry is key. Even signed RMM tools become dangerous if they spawn unauthorized shells. We’ve had success hunting for specific parent-child anomalies using PowerShell:
Get-CimInstance Win32_Process | Where-Object { $_.ParentProcessName -match '(AnyDesk|TeamViewer)' -and $_.Name -match '(cmd|powershell)\\.exe' }
To expand on the behavioral checks, we should look at the persistence mechanism. Many RMS agents register as Windows services immediately. We've found success hunting for RMM binaries creating services, especially when the parent process is a user application like Word or a browser. This KQL query helps catch that specific installation chain:
DeviceProcessEvents
| where FileName in~ ("tvw.exe", "anydesk.exe", "aegng.exe")
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "chrome.exe")
It catches the setup phase before the full connection is established.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access