New Malware Family Using CLFS Log Files To Evade Detection

Cybersecurity researchers of FireEye’s Mandiant Advanced Practices team have revealed all the details regarding a new malware family that they have detected recently. 

This malware depends on the Common Log File System (CLFS) to cover a second-stage payload in registry transaction files so that they can easily evade detection mechanisms.

The security experts from FireEye reported that the malware is being called PRIVATELOG, and its installer, STASHLOG. They generally specify the integrity of the cybercriminals, but the main motive of the threat actors is not yet unclear.

CLFS and Transaction Files

CLFS is a logging framework that has been produced and published by Microsoft in Windows Vista and Windows Server 2003 R2 for great execution. This logging framework usually renders applications along with API functions that are possible in clfsw32.dll to create, store and read log data.

On the other hand, CLFS is prominently used by the Kernel Transaction Manager (KTM) for both Transactional NTFS (TxF) as well as Transactional Registry (TxR) operations. 

These transactions enable applications to implement few changes either on the file system or in the registry. However, all of them were arranged in a single transaction which can easily be committed or rolled back.

Malware Obfuscation

According to the investigation report, almost all the strings that are used by PRIVATE LOG and STASHLOG are obfuscated, but the important point is that the methods that have been observed in the malware are quite uncommon.

The security experts have pronounced that these methods rely on XOR’ing each byte with a hard-coded byte inline, that has no specific loops, therefore each and every string of this malware is encrypted with a unique byte stream.

Stashing the Payload

After the launch, the installer opens and decrypts the whole contents of the file that has been transferred as a contention. 

Not only this but it also confirms that the file has been suffixed by its SHA1 hash, and then creates the same 56-byte value just by using the collected GlobalAtom GUID string in memory of the system.

However, the 56-byte value is SHA1 that has been hashed and the first 16-bytes has formed the initialization vector (IV). But, the main key is the 16-byte MachineGUID value from the host’s registry, and the encryption algorithm is HC-128, which can be used by the threat actors very rarely.

Onto PRIVATELOG

Moreover, the security analysts of Mandiant are an un-obfuscated 64-bit DLL named prntvpt.dll and it comprises exports, which simulate those of legitimate prntvpt.dll files. PRIVATELOG generally gets loaded from PrintConfig.dll, that is the central DLL of service described PrintNotify, through DLL search order hijacking.

Not only this but PRIVATELOG certainly uses a very unique way to execute the DLL payload, and as per the report the payloads rely on NTFS transactions.

So, that’s why they suggest that organizations must implement YARA rules to scan their internal networks, as it will tell you if any malware is present in that or not. 

Not only this but it also helps to watch out for potential Indicators of Compromise (IoCs) in “method”, “imageload” or “filewrite” events linked with endpoint detection and response (EDR) system logs.

You can follow us on Linkedin, Twitter, Facebook for daily Cybersecurity and hacking news updates.