Qilin ransomware caught stealing credentials stored in Google Chrome

During a recent investigation of a Qilin ransomware breach, the Sophos X-Ops team identified attacker activity leading to en masse theft of credentials stored in Google Chrome browsers on a subset of the network's endpoints - a credential-harvesting technique with potential implications far beyond the original victim's organization. This is an unusual tactic, and one that could be a bonus multiplier for the chaos already inherent in ransomware situations.

What is Qilin?

The Qilin ransomware group has been in operation for just over two years. It was in the news in June 2024 due to an attack on Synnovis, a governmental service provider to various UK healthcare providers and hospitals. Prior to the activity described in this post, Qilin attacks have often involved "double extortion" - that is, stealing the victim's data, encrypting their systems, and then threatening to reveal or sell the stolen data if the victim won't pay for the encryption key, a tactic we've recently discussed in our "Turning the Screws" research

The Sophos IR team observed the activity described in this post in July 2024. To provide some context, this activity was spotted on a single domain controller within the target's Active Directory domain; other domain controllers in that AD domain were infected but affected differently by Qilin.

Opening maneuvers

The attacker obtained initial access to the environment via compromised credentials. Unfortunately, this method of initial access is not new for Qilin (or other ransomware gangs for that matter). Our investigation indicated that the VPN portal lacked multifactor authentication (MFA) protection.

The attacker's dwell time between initial access to the network and further movement was eighteen days, which may or may not indicate that an Initial Access Broker (IAB) made the actual incursion. In any case, eighteen days after initial access occurred, attacker activity on the system increased, with artifacts showing lateral movement to a domain controller using compromised credentials.

Once the attacker reached the domain controller in question, they edited the default domain policy to introduce a logon-based Group Policy Object (GPO) containing two items. The first, a PowerShell script named IPScanner.ps1, was written to a temporary directory within the SYSVOL (SYStem VOLume) share (the shared NTFS directory located on each domain controller inside an Active Directory domain) on the specific domain controller involved. It contained a 19-line script that attempted to harvest credential data stored within the Chrome browser.

The second item, a batch script named logon.bat, contained the commands to execute the first script. This combination resulted in harvesting of credentials saved in Chrome browsers on machines connected to the network. Since these two scripts were in a logon GPO, they would execute on each client machine as it logged in.

On the endpoints

Whenever a logon occurred on an endpoint, the logon.bat would launch the IPScanner.ps1 script, which in turn created two files - a SQLite database file named LD and a text file named temp.log, as seen in Figure 1.

[Link]

Figure 1: We call this demo device Hemlock because it's poisonous: The two files created by the startup script on an infected machine

These files were written back to a newly created directory on the domain's SYSVOL share and named after the hostname of the device(s) on which they were executed (in our example, Hemlock)

The LD database file contains the structure shown in Figure 2.

[Link]

Figure 2: Inside LD, the SQLite database file dropped into SYSVOL

In a display of confidence that they would not be caught or lose their access to the network, the attacker left this GPO active on the network for over three days. This provided ample opportunity for users to log on to their devices and, unbeknownst to them, trigger the credential-harvesting script on their systems. Again, since this was all done using a logon GPO, each user would experience this credential-scarfing each time they logged in.

To make it more difficult to assess the extent of the compromise, once the files containing the harvested credentials were stolen and exfiltrated, the attacker deleted all the files and cleared the event logs for both the domain controller and the infected machines. After deleting the evidence, they proceeded to encrypt files and drop the ransom note, as shown in Figure 3. This ransomware leaves a copy of the note in every directory on the device on which it runs.

[Link]

Figure 3: A Qilin ransom note

The Qilin group used GPO again as the mechanism for affecting the network by having it create a scheduled task to run a batch file named run.bat, which downloaded and executed the ransomware.

Impact

In this attack, the IPScanner.ps1 script targeted Chrome browsers - statistically the choice most likely to return a bountiful password harvest, since Chrome currently holds just over 65 percent of the browser market. The success of each attempt would depend on exactly what credentials each user was storing in the browser. (As for how many passwords might be acquired from each infected machine, a recent survey indicates that the average user has 87 work-related passwords, and around twice as many personal passwords.)

A successful compromise of this sort would mean that not only must defenders change all Active Directory passwords; they should also (in theory) request that end users change their passwords for dozens, potentially hundreds, of third-party sites for which the users have saved their username-password combinations in the Chrome browser. The defenders of course would have no way of making users do that. As for the end-user experience, though virtually every internet user at this point has received at least one "your information has been breached" notice from a site that has lost control of their users' data, in this situation it's reversed - one user, dozens or hundreds of separate breaches.

It's perhaps interesting that, in this specific attack, other domain controllers in the same Active Directory domain were encrypted, but the domain controller where this specific GPO was originally configured was left unencrypted by the ransomware. What this might have been - a misfire, an oversight, attacker A/B testing - is beyond the scope of our investigation (and this post).

Conclusion

Predictably, ransomware groups continue to change tactics and expand their repertoire of techniques. The Qilin ransomware group may have decided that, by merely targeting the network assets of their target organizations, they were missing out.

If they, or other attackers, have decided to also mine for endpoint-stored credentials - which could provide a foot in the door at a subsequent target, or troves of information about high-value targets to be exploited by other means - a dark new chapter may have opened in the ongoing story of cybercrime.

Acknowledgements

Anand Ajjan of SophosLabs, as well as Ollie Jones and Alexander Giles from the Incident Response team, contributed to this analysis.

Response and remediation

Organizations and individuals should rely on password managers applications that employ industry best practices for software development, and which are regularly tested by an independent third party. The use of a browser-based password manager has been proven to be insecure time and again, with this article being the most recent proof.

Multifactor authentication would have been an effective preventative measure in this situation, as we've said elsewhere. Though use of MFA continues to rise, a 2024 Lastpass study indicates that though MFA adoption at companies with over 10,000 employees is a not-terrible 87%, that adoption level drops precipitously - from 78% for companies with 1,001-1000 employees all the way down to a 27% adoption rate for businesses with 25 employees or less. Speaking bluntly, businesses must do better, for their own safety - and in this case, the safety of other companies as well.

Our own Powershell.01 query was instrumental in identifying suspicious PowerShell commends executed in the course of the attack. That query is freely available from our Github, along with many others.

Sophos detects Qilin ransomware as Troj/Qilin-B and with behavioral detections such as Impact_6a & Lateral_8a. The script described above is detected as Troj/Ransom-HDV.

Public link

Please use the above public link if you want to share this noodl on another website.