Listen to this Post

Introduction:
The cybersecurity landscape is witnessing a dangerous evolution in Remote Access Trojans (RATs). MostereRAT exemplifies this shift, moving beyond easily detectable custom payloads to weaponizing trusted enterprise software like AnyDesk, TightVNC, and native RDP, granting attackers undetected, persistent access. This sophisticated approach bypasses traditional security heuristics by blending malicious activity with legitimate, whitelisted network traffic.
Learning Objectives:
- Understand the technical mechanisms MostereRAT uses to achieve persistence and elevate privileges.
- Learn to detect and mitigate malicious abuse of legitimate remote access tools.
- Master advanced forensic commands to identify signs of a system compromise involving these tools.
You Should Know:
1. Detecting Unauthorized AnyDesk Installation
AnyDesk, while a legitimate tool, is a common post-exploitation payload. Attackers install it to maintain remote access.
Linux/MacOS: Check for AnyDesk processes and files
ps aux | grep -i anydesk
ls -la /tmp/ /var/tmp/ | grep -i anydesk
find / -name "anydesk" 2>/dev/null
Windows: Check for AnyDesk in Program Files, AppData, and services
Get-Process | Where-Object {$<em>.ProcessName -like "anydesk"}
Get-ChildItem -Path "C:\Program Files", "C:\ProgramData", "$env:USERPROFILE\AppData" -Recurse -Include "anydesk" -ErrorAction SilentlyContinue
Get-Service | Where-Object {$</em>.DisplayName -like "anydesk"}
Step-by-step guide: After initial access, attackers often drop AnyDesk into temporary or user writable directories. The `ps aux` command lists all running processes; filter for AnyDesk to identify active sessions. The `find` command searches the entire filesystem for any related files. On Windows, `Get-Process` and `Get-ChildItem` are your primary tools for hunting the executable. Always check for services (Get-Service) as attackers will often create one for persistence.
2. Investigating Suspicious Service Creation
MostereRAT is known to hide its service creation method. Auditing the system for new, unusual services is critical.
Windows: Query System and Security event logs for service creation
Get-WinEvent -FilterHashtable @{LogName='System'; ID=7045} | Where-Object {$<em>.Message -like "anydesk" -or $</em>.Message -like "tightvnc"} | Format-List -Property TimeCreated, Message
PowerShell: Get all non-Microsoft services
Get-WmiObject -Class Win32_Service | Where-Object {$<em>.Caption -notlike "Microsoft" -and $</em>.PathName -notlike "Windows"} | Select-Object Name, DisplayName, State, PathName, StartMode
Step-by-step guide: Windows Event ID 7045 in the System log records every new service installation. Filter this log for the names of known remote access tools. The WMI query helps build a baseline of all services not provided by Microsoft, which should be investigated for legitimacy. Pay close attention to services running from unusual paths like `C:\Temp` or C:\Users\Public.
3. Blocking AV Traffic with Windows Firewall
A hallmark of this campaign is its ability to block antivirus solution traffic, crippling defenses.
Windows: List all active firewall rules that block traffic
Get-NetFirewallRule | Where-Object {$_.Action -eq "Block"} | Format-Table -Property DisplayName, Enabled, Profile, Direction
Windows: Check for rules blocking specific AV executables or domains
Get-NetFirewallRule -DisplayName "defender" | Get-NetFirewallApplicationFilter
Get-NetFirewallRule -DisplayName "crowdstrike" | Get-NetFirewallApplicationFilter
Get-NetFirewallRule -DisplayName "sentinel" | Get-NetFirewallApplicationFilter
Step-by-step guide: Use the `Get-NetFirewallRule` cmdlet to audit all blocking rules. Attackers may add rules that prevent your EDR/AV agent from communicating with its cloud console. Look for rules that block outbound traffic on common ports (80, 443, 53) or that specifically target the executable paths of your security software.
4. Auditing for RDP Wrapper Misconfigurations
RDP Wrapper is a popular library that enables multiple simultaneous RDP sessions on Windows; attackers abuse it for access.
Windows: Check the current state of the RDP service and its configuration Get-Service -Name TermService -RequiredServices Checks the RDP service (TermService) and its dependencies reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections Query the RDP connection setting (0=allowed, 1=denied) reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber Check if the default RDP port has been changed
Step-by-step guide: The `Get-Service` command confirms if the RDP service is running. The `reg query` commands are essential for checking the core configuration in the Windows Registry. A value of `0` for `fDenyTSConnections` means RDP is enabled. Attackers may change the default port (3389) to something else to evade basic network scans.
5. Hunting for TightVNC Artifacts
TightVNC leaves distinct traces in the filesystem and registry that can be hunted.
Windows: Check for common TightVNC installation paths and registry keys dir /s /b "C:\Program Files\TightVNC" 2>nul dir /s /b "C:\Program Files (x86)\TightVNC" 2>nul reg query "HKLM\SOFTWARE\TightVNC" /s 2>nul reg query "HKCU\SOFTWARE\TightVNC" /s 2>nul Check for running TightVNC processes (server is typically 'tvnserver') tasklist /FI "IMAGENAME eq tvnserver.exe"
Step-by-step guide: These commands search the standard program installation directories and the registry for any keys related to TightVNC. The `tasklist` command filters for the primary TightVNC server process. Because these tools are often installed in non-standard locations, consider using a broad file search tool like `Everything` if these commands come up empty but suspicion remains high.
6. Analyzing Network for mTLS Anomalies
MostereRAT’s use of mutual TLS (mTLS) makes its C2 traffic appear legitimate. Detecting it requires analyzing certificate anomalies.
Linux: Use tools like tshark or zeek to analyze TLS handshakes and spot client certificate authentication tshark -r packet_capture.pcap -Y "ssl.handshake.type == 1" -T fields -e ip.src -e ssl.handshake.extensions_server_name Find Client Hello messages and SNI tshark -r packet_capture.pcap -Y "ssl.handshake.type == 11" -V | grep -A5 -B5 "Certificate" Find Certificate messages within handshakes Check for connections to known VNC/RDP/AnyDesk infrastructure zeek -r traffic.pcap | grep -i "anydesk|tightvnc|rdp" | head -20
Step-by-step guide: mTLS involves the client presenting a certificate to the server. In a typical TLS connection (e.g., web browsing), only the server presents a cert. The first `tshark` command finds all initial TLS connections (Client Hello). The second command digs into the specific packets where certificates are exchanged (type == 11), which can reveal the client certs used by the malware. Zeek can help quickly flag traffic to known tool domains.
7. System Forensics for TrustedInstaller Privilege Abuse
The malware’s ability to run as TrustedInstaller is a significant privilege escalation, granting it extreme system authority.
Windows: Use Sysinternals Process Explorer to verify process tokens
Graphical tool: Look for processes running as "NT SERVICE\TrustedInstaller"
Windows: Search recent Event Logs for instances of the TrustedInstaller SID (S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)
Get-WinEvent -LogName Security | Where-Object {$_.Message -like "S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464"} -MaxEvents 20
Step-by-step guide: Direct command-line investigation of TrustedInstaller activity is complex. The most efficient method is to use Sysinternals Process Explorer, filtering for and examining any process running under that identity. For a deeper forensic dive, you can search the Security event log for the unique Security Identifier (SID) associated with the TrustedInstaller service, which may log its activation.
What Undercode Say:
- Legitimate Tools Are the New Attack Vector. The most critical takeaway is that perimeter and endpoint defenses tuned to block known-bad executables and signatures are blind to this threat. Security teams must immediately shift focus to monitoring for the anomalous behavior and misuse of legitimate software, regardless of its origin.
- Persistence Trumps Initial Access. The sophistication of MostereRAT is not in its initial infection vector but in its multi-layered persistence mechanism. Defenders must assume breach and prioritize hunting for persistence—like unauthorized services, scheduled tasks, and registry modifications—above all else.
The analysis reveals a fundamental change in the attacker playbook. By co-opting tools that are necessary for business operations, attackers create a dilemma for defenders: block critical software and disrupt business, or allow it and accept the risk. This forces a strategic pivot from simple allow/deny listing to more nuanced behavioral analytics and application control that can distinguish between normal and malicious use of AnyDesk, VNC, and RDP. The bar for defensive capability has been raised significantly.
Prediction:
The success of campaigns like MostereRAT will catalyze a massive shift in the cybercriminal underground. Within the next 18-24 months, we predict that the vast majority of sophisticated ransomware and cyber-espionage groups will abandon custom C2 channels in favor of leveraging and abusing legitimate remote access and cloud collaboration platforms. This will erode the effectiveness of traditional network-based IoC blocking and force mass adoption of Zero-Trust principles, behavioral AI detection, and stricter internal software governance policies as the primary defensive controls. The line between legitimate enterprise traffic and malicious command-and-control will be all but erased.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Jamie Williams – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅


