Unraveling the Mystery: Inside the Qilin Ransomware Attack

Written by Lindsey O’Donnell-Welch, Ben Folland, Harlan Carvey of Huntress Labs.

A big part of a security analyst’s everyday role is figuring out what actually happened during an incident. We can do that by piecing together breadcrumbs–whether that’s through logs, antivirus detections, and other clues–that help us understand how the attacker achieved initial access and what they did after.

However, it’s not always cut and dry: sometimes there are external factors that limit our visibility. The Huntress agent might not be deployed across all endpoints, for example, or the targeted organization might install the Huntress agent after a compromise has already occurred.

In these cases, we need to get creative and look at multiple data sources in order to determine what actually happened.

Recently, we analyzed an incident where both of the above factors were true: on October 11, an organization installed the Huntress agent post-incident, and initially on one endpoint.

When it comes to visibility, this incident was less about looking through a keyhole, and more akin to looking through a pinhole. Even so, Huntress analysts were able to derive a great deal of information regarding the incident.

The Qilin incident: What we started with

The Huntress agent was installed on a single endpoint following a Qilin ransomware infection. What does that mean from the perspective of an analyst trying to figure out what happened?

We had limited clues to start: there was no endpoint detection and response (EDR) or SIEM telemetry available, and Huntress-specific ransomware canaries weren’t tripped. Because we were also on one endpoint, our visibility was limited to the activity that had occurred on that specific endpoint within the broader environment’s infrastructure.

As a result, all Huntress analysts had to start with to unravel this incident was the managed antivirus (MAV) alerts. Once the Huntress agent was added to the endpoint, the SOC was alerted to existing MAV detections, some of which are illustrated in Figure 1.

Analysts began tasking files from the endpoint, starting with a specific subset of the Windows Event Logs (WEL).

From those logs, analysts could see that on 8 Oct 2025, the threat actor accessed the endpoint and installed the Total Software Deployment Service, as well as a rogue instance of the ScreenConnect RMM, one that pointed to IP address 94.156.232[.]40.

Searching VirusTotal for the IP address provided the insight illustrated in Figure 2.

An interesting aspect of the installation was that LogMeIn was apparently legitimately installed on the endpoint on 20 Aug 2025 from the file %user%\Downloads\LogMeIn.msi.

Then, on 8 Oct, the rogue ScreenConnect instance was installed from the file C:\Users\administrator\AppData\Roaming\Installer\LogmeinClient.msi.

Further, the timeline indicates that on 2 Oct, the file %user%\Downloads\LogMeIn Client.exe was submitted by Windows Defender for review, and no other action was taken after that event.

Pivoting from the ScreenConnect installation to ScreenConnect activity events within the timeline of activity, analysts saw that on 11 Oct, three files were transferred to the endpoint via the ScreenConnect instance; r.ps1, s.exe, and ss.exe.

Digging in a bit deeper, only r.ps1 was still found on the endpoint (shown below).

      $RDPAuths = Get-WinEvent -LogName

      'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational'

      -FilterXPath @'

      <QueryList><Query Id="0"><Select>

        *[System[EventID=1149]]

      </Select></Query></QueryList>

      '@

      # Get specific properties from the event XML

      [xml[]]$xml=$RDPAuths|Foreach$_.ToXml()

      $EventData = Foreach ($event in $xml.Event) 

        # Create custom object for event data

        New-Object PSObject -Property @

         TimeCreated = (Get-Date ($event.System.TimeCreated.SystemTime) -Format 'yyyy-MM-dd hh:mm:ss K')

         User = $event.UserData.EventXML.Param1

         Domain = $event.UserData.EventXML.Param2

         Client = $event.UserData.EventXML.Param3

   

      $EventData | FT

Based on the contents of the script, it would appear that the threat actor was interested in determining IP addresses, domains, and usernames associated with RDP accesses to the endpoint.

However, the Windows Event Log contained a Microsoft-Windows-PowerShell/4100 message stating:

Error Message = File C:\WINDOWS\systemtemp\ScreenConnect\22.10.10924.8404\Files\r.ps1 cannot be loaded because running scripts is disabled on this system.

This message was logged within 20 seconds of the script being transferred to the endpoint, and the threat actor attempting to run it.

Parsing through PCA logs

The other two files, s.exe and ss.exe, took a bit more work to unravel, because they were no longer found on the endpoint.

However, Huntress analysts were able to take advantage of data sources on the Windows 11 endpoint, specifically the AmCache.hve file and the Program Compatibility Assistant (PCA) log files to obtain hashes for the files, and to see that while the threat actor had attempted to execute the files, both apparently failed.

The threat actor disabled Windows Defender, which were seen in Windows Defender event records, starting with event ID 5001, indicating that the Real-Time Protection feature was disabled. This was followed by several event ID 5007 records, indicating that features such as SpyNetReporting and SubmitSamplesConsent had been modified (in this case, disabled), as well as SecurityCenter messages indicating that Windows Defender had entered a SECURITY_PRODUCT_STATE_SNOOZED state.

The threat actor then attempted to launch s.exe, which was almost immediately followed by the message “Installer failed” in the PCA logs. Based on the identified VirusTotal detections shown in Figure 3, and the behaviors identified by VirusTotal, this file appears to be an infostealer.

The messages in the PCA logs provide indications that the file, identified as an installer, failed to execute.

Seven seconds later, the threat actor attempted to run ss.exe, which was immediately followed by the legitimate Windows application, c:\windows\syswow64\werfault.exe, being launched.