Listen to this Post
Introduction:
Recent cybersecurity observations reveal that the Qilin ransomware gang has evolved its post-compromise reconnaissance by using native PowerShell commands to silently enumerate Remote Desktop Protocol (RDP) authentication history on compromised servers. This stealthy technique, which extracts Event ID 1149 logs from the `Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational` log to map network pivot points and identify privileged accounts, allows attackers to evade traditional detection tools while planning lateral movement. Understanding and hunting this behavior is critical for defenders to stop double-extortion ransomware before encryption begins.
Learning Objectives:
- Understand how Qilin ransomware operators use PowerShell to extract RDP authentication history for network mapping.
- Learn to detect this stealthy enumeration technique using Sysmon, Windows Event Logs, and custom threat-hunting queries.
- Implement hardening measures and logging configurations to defend against RDP-based lateral movement.
You Should Know:
1. How Attackers Enumerate RDP History with PowerShell
The Qilin ransomware group has been observed using a single PowerShell command to pull every remote desktop authentication attempt from the Windows event logs. Instead of deploying noisy network scanners that trigger alarms, attackers use the built-in `Get-WinEvent` cmdlet to stealthily gather intelligence. Below is the exact pattern of the command observed in the wild, pulling from Event ID 1149 which logs each RDP connection, including the username, domain, and source IP address of the client.
Technical Breakdown – Command Functionality and Usage:
Step‑by‑Step Guide (What the Attacker Does):
Step 1 – Map the Event Source:
The attacker first checks which Windows event log contains RDP connection history. RDP authentication events are stored in the `Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational` log, specifically under Event ID 1149 for successful connections. To verify this, an attacker might run:
wevtutil gl Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
Step 2 – Extract All RDP Authentication Events:
The core PowerShell command used by Qilin is:
Get-WinEvent -LogName Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational | Where-Object { $<em>.Id -eq 1149 }
A more refined version pulls only the needed fields (timestamp, user, domain, source IP) for rapid network pivoting:
Get-WinEvent -LogName Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational | Where-Object { $</em>.Id -eq 1149 } | ForEach-Object { $_.Properties }
Alternatively, attackers may query the Security log for RDP logon events (Logon Type 10) using Event IDs 4624 (successful) and 4625 (failed), as these also provide user account details and source IP information.
Step 3 – Enumeration of the RDP Connection Cache in the Registry:
Beyond live logs, attackers also look at the RDP client connection history stored in the registry under `HKCU\Software\Microsoft\Terminal Server Client\Servers` and \Default. A single PowerShell command can extract all previously connected hostnames:
Get-ItemProperty -Path "HKCU:\Software\Microsoft\Terminal Server Client\Servers" | Select-Object -ExpandProperty PSChildName
This registry key contains the list of all servers the compromised user has connected to via RDP, providing immediate lateral movement targets for the attacker.
For System Administrators and Defenders:
To test if your environment is vulnerable, you can simulate this detection by running a controlled enumeration from a test machine. For example:
Enumerate recent RDP connections from current user
Get-ChildItem "HKCU:\Software\Microsoft\Terminal Server Client\Servers" | ForEach-Object { $<em>.PSChildName; (Get-ItemProperty -Path $</em>.PSPath).UsernameHint }
- How to Detect This Stealthy Lateral Movement Technique
Detecting Qilin’s PowerShell‑based reconnaissance requires proactive logging and hunting across multiple data sources. Because this technique uses built‑in Windows tools, it does not generate obvious alerts, but leaves forensic artifacts in event logs, Sysmon data, and PowerShell transcripts.
Step‑by‑Step Guide (For Blue Teams and SOC Analysts):
Step 1 – Enable Enhanced PowerShell Logging:
To capture the actual script blocks that attackers execute, enable PowerShell Script Block Logging (Event ID 4104) and Module Logging (Event ID 4103). This can be done via Group Policy:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1
With this enabled, any execution of `Get-WinEvent` to access RDP logs will be recorded in the `Microsoft-Windows-PowerShell/Operational` log with Event ID 4104, showing the full command string. Attackers may attempt to bypass this by disabling AMSI (Antimalware Scan Interface) or deleting specific registry keys, which themselves generate additional alertable events (e.g., Sysmon Event ID 13 for AMSI provider deletion).
Step 2 – Deploy Sysmon with a Custom Configuration:
Sysmon (System Monitor) provides deep visibility into process creation, network connections, and command-line arguments. A well‑tuned Sysmon configuration logs Event ID 1 (process creation) with the full command line for `powershell.exe` and cmd.exe. Install Sysmon with a configuration that focuses on unusual PowerShell parameters:
sysmon64 -accepteula -i sysmonconfig-export.xml
Then monitor for PowerShell processes with command lines containing `Get-WinEvent` and terms like TerminalServices, RemoteConnectionManager, or `LogName` and 1149.
Step 3 – Hunt for RDP Enumeration Using KQL and Sigma Rules:
For cloud‑native SIEMs like Microsoft Sentinel or M365 Defender, use KQL (Kusto Query Language) to hunt for these events across all devices. A sample KQL query to find suspicious RDP enumeration:
DeviceProcessEvents
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has "Get-WinEvent" and ProcessCommandLine has "TerminalServices"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
Additionally, Sigma rules are available to convert to SIEM platforms. Create a Sigma rule detecting the specific combination of Event ID 4104 and a command line containing `Get-WinEvent` and `4624` or 1149. These rules can be sourced from threat‑hunting repositories, such as those associated with Qilin detection packs.
Step 4 – Analyze Security Event Logs for Unusual Logon Patterns:
Windows Event IDs 4624 (successful logon) and 4625 (failed logon) are key indicators of RDP use. Focus on Logon Type 10 (RemoteInteractive) for direct RDP access. However, be aware that Network Level Authentication (NLA) can initially log RDP connections as Logon Type 3 (Network), so correlate with other events like 4648 (logon using explicit credentials) to avoid missing attacks. A hunting script to identify anomalous RDP logon times (e.g., outside business hours) can be built using Get‑WinEvent, ironically the same tool the attackers use:
Get-WinEvent -LogName Security | Where-Object { $<em>.Id -eq 4624 -and $</em>.Properties[bash].Value -eq 10 } | Select-Object TimeCreated, @{Name="User";Expression={$<em>.Properties[bash].Value}}, @{Name="SourceIP";Expression={$</em>.Properties[bash].Value}}
- Advanced Defenses and Hardening Against RDP‑Based Lateral Movement
Because Qilin’s technique relies on successfully logging into a server via RDP to begin with, prevention and hardening are critical. The group often obtains initial access through compromised credentials, sometimes from VPN portals lacking multifactor authentication. Once inside, they move laterally using stolen credentials and the enumerated RDP targets.
Step‑by‑Step Guide (For System Hardening and Configuration):
Step 1 – Enforce Network Level Authentication (NLA) and Multifactor Authentication (MFA):
NLA requires users to authenticate before a full RDP session is established, reducing the attack surface and preventing certain brute‑force and credential‑replay attacks. Enable NLA via Group Policy: navigate to Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security, then set “Require user authentication for remote connections by using Network Level Authentication” to Enabled. Additionally, enforce MFA for all RDP access, ideally via a Remote Desktop Gateway or a VPN solution that integrates Azure MFA or similar. Direct exposure of RDP (TCP port 3389) to the internet must be eliminated.
Step 2 – Restrict RDP Access Using Firewall and IP Whitelisting:
Configure the Windows Defender Firewall to limit RDP source IP addresses to a defined set of administrative jump boxes or a specific subnet. Use PowerShell to restrict port 3389 to a specific IP range:
New-NetFirewallRule -DisplayName "RDP Restricted" -Direction Inbound -LocalPort 3389 -Protocol TCP -Action Allow -RemoteAddress 192.168.1.0/24
In cloud environments (Azure, AWS), configure network security groups (NSGs) or security groups to allow RDP only from bastion host IPs.
Step 3 – Implement Account Lockout Policies and Monitor for Brute Force:
Set a Group Policy that locks out accounts after a small number of failed logins (e.g., 5 attempts within 15 minutes). This can slow down or stop credential brute‑forcing. Additionally, configure the system to alert on repeated Event ID 4625 (failed logon) for any account, especially those with administrative privileges.
Step 4 – Reduce the Attack Surface by Removing Unused RDP “Pivot Points”:
Regularly audit servers and workstations to ensure that RDP is disabled on systems that do not require remote management. Use the following PowerShell to audit RDP enablement across the network:
Get-WmiObject -Class Win32_TerminalServiceSetting -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'" | Select-Object AllowTSConnections
Disable RDP on all non‑essential servers via Group Policy or PowerShell (Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" -Value 1).
- Incident Response: What to Do When Qilin Is Discovered
If your threat‑hunting efforts reveal that Qilin has already enumerated RDP history on a compromised server, immediate action is required to contain the breach and preserve evidence for forensic analysis.
Step‑by‑Step Guide (For Incident Responders):
Step 1 – Isolate the Compromised System:
Disconnect the server from the network to prevent the attackers from using the enumerated RDP targets for lateral movement. However, keep the machine powered on to preserve volatile memory and active network connections for forensic acquisition.
Step 2 – Capture Forensic Artifacts:
Preserve the event logs, PowerShell operational logs, and Sysmon logs from the affected server. Extract the attacker’s PowerShell command lines by exporting Event ID 4104 logs:
wevtutil epl Microsoft-Windows-PowerShell/Operational PowerShellLogs.evtx
Also collect the RDP cache files located under %systemdrive%\Users\<username>\AppData\Local\Microsoft\Terminal Server Client\Cache. These bitmap cache files can be stitched together using tools like `RdpCacheStitcher` to potentially reconstruct the attacker’s remote screen views, revealing which applications and data they accessed.
Step 3 – Identify Lateral Movement Targets:
Examine the enumerated RDP connection list that the attacker extracted. This will show which other systems the threat actor accessed. For each target host, examine its logs for signs of intrusion, such as new user accounts, scheduled tasks, or service installations. Qilin has been observed installing rogue remote management tools like ScreenConnect to maintain persistent access.
Step 4 – Revoke Compromised Credentials and Reset Passwords:
Based on the accounts the attacker enumerated and used (found in Event ID 4624 logs for RDP sessions), reset those passwords immediately. Require MFA re‑enrollment for all affected accounts. Disable any accounts that appear suspicious and were possibly created by the attacker.
What Undercode Say:
- Evasion through Legitimacy is the New Norm. Qilin’s reliance on `Get-WinEvent` – a tool used daily by admins – shows that attackers no longer need custom malware to perform critical reconnaissance. Defense must pivot from merely blocking “bad” tools to detecting abnormal use of legitimate ones.
-
Visibility Saves Networks. Without Script Block Logging (Event ID 4104) and a properly configured Sysmon, this PowerShell ‑based enumeration is essentially invisible. The low cost of enabling these logs is minuscule compared to the cost of a double-extortion ransomware event.
-
RDP is a Double-Edged Sword. The same protocol that provides administrative convenience is the primary highway for lateral movement. Enforcing NLA and MFA for every RDP session, and eliminating internet‑facing RDP, are no longer optional – they are essential controls.
Prediction:
As defensive logging improves, expect Qilin and other RaaS groups to evolve their automated reconnaissance scripts to use more obfuscation, such as splitting the `Get-WinEvent` command into multiple strings or using encoded commands to bypass Script Block Logging. Attackers may also shift to alternative lateral movement protocols, like WinRM or WMI, to avoid the visibility provided by RDP event logs. Organizations that adopt zero‑trust principles – including continuous authentication and strict network segmentation – will be best positioned to nullify this class of discovery tactics. The cat‑and‑mouse game of ransomware detection will increasingly focus on the post‑compromise phase, making dedicated threat‑hunting teams a necessity rather than a luxury.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Varshu25 Qilin – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
