A signed kernel driver now hides the CoolClient backdoor on Windows

Kaspersky has published an analysis of a new version of the CoolClient backdoor. The new version installs a signed driver in the Windows kernel, and that driver hides the malware's own process and protects the files and registry keys it uses. Kaspersky attributes the activity to the espionage group HoneyMyte, also known as Mustang Panda. According to the analysis, victims were found in Myanmar, Mongolia, Pakistan and Russia, among them confirmed government entities. In every intrusion Kaspersky examined, CoolClient arrived as a second backdoor following a PlugX infection.

What happens technically

The attack begins with a program that is entirely legitimate. In the campaign against Myanmar the actor first created two exclusions in Microsoft Defender, one for a folder and one for a file, so that the directory the malware was to use would not be scanned. The actor then built a folder resembling the real Windows Defender folder, copied the malware components into it, and renamed a legitimate Sangfor program to defender.exe. When that program starts, it loads the library libngs.dll from its own folder, and what sits there is the malicious version rather than the real one. The technique is called DLL sideloading, and it works because Windows looks in the directory of the program itself first. So that the malware survives a restart, a scheduled task is created that runs under the SYSTEM account, and the task carries a name resembling one of Defender's own services.

The new part is what follows. If the process holds administrator rights, it extracts a driver stored compressed inside the malware, writes it to disk as msagent.sys and starts it as a Windows service. The user mode component then opens a device in the kernel and sends three control messages, known as IOCTLs. The first registers the malware process as trusted, the second passes the address of the command server, and the third lists the file paths and registry keys the driver is to protect. The driver does the rest using extension points Windows offers itself. It removes the process from the list the operating system uses when it shows which processes are running. It registers a file system filter that denies access to the folders on the list. And it registers a routine that Windows calls on registry lookups, so that the protected keys drop out of the answer before it arrives. Processes not registered as trusted receive reduced access when they try to open the malware process, which leaves them unable either to terminate it or to look inside it.

Two details from the analysis deserve attention. The driver is signed with a certificate issued to Nanjing Ranyi Technology Co., Ltd., and that certificate was valid from August 2013 to September 2014. Kaspersky found several older malicious drivers signed with the same certificate, but writes that nothing links them directly to this activity. The second detail is that the whole driver stage is skipped when the process lacks administrator rights. The malware then moves straight to its final stage, and the machine is left with a backdoor that the kernel does not conceal.

What this means for you if you monitor Windows endpoints

The victims in this campaign are in Asia, and the sources say nothing about organisations in Norway. The method is nonetheless the one you meet at home. If you hold exclusions in Microsoft Defender for a folder or a file, they are worth a review today, because an exclusion of exactly that kind is what the attacker created here. Berigo assesses that exclusions are rarely documented with who asked for them and why, and an exclusion nobody can account for is a place nobody looks. The same holds for scheduled tasks running as SYSTEM, where the name may have been chosen to resemble something you trust.

You should also expect a driver to stand in the way of your investigation. Once the malware has a driver in the kernel, the machine gives you wrong answers about itself. The process does not appear in the list, Windows reports that the folder does not exist, and the registry key never shows up in the lookup. Searching the machine while it runs is then of little help. Berigo assesses that the answer has to come from somewhere else, from the traffic the machine sends, from logs already collected off the machine, and from a disk image taken after the machine has been powered off. Under NIS2 article 21 this belongs to incident handling, and being able to examine a machine you no longer trust is part of that preparedness.

Berigo recommends

• Review every exclusion in Microsoft Defender, and require each one to have an owner and a written justification.
• Look for scheduled tasks running as SYSTEM with names resembling Microsoft's own services.
• Enable Microsoft's blocklist for vulnerable drivers, and verify that it actually takes effect on the machines.
• Make sure security logs leave the machine continuously, so they exist even when the machine hides the traces locally.
• Have a plan for examining a machine you do not trust, and rehearse it before you need it.