New malware group uses CLFS to bypass detection
FireEye’s Mandiant Advanced Practices team has discovered a new malware family that depends on the Common Log File System (CLFS) to hide a payload in registry transaction files with the objective of evading detection mechanisms.
The researchers named the malware PRIVATELOG. They dubbed its installer STASHLOG. Details about the threat actor or their aims are still not clear.
The malware is yet to be spotted in real-world scenarios, Mandiant suspects that the malware could still be in development or deployed as part of a highly targeted action.
Also Read: New AdLoad malware variant evades Apple’s XProtect defenses
CLFS is a logging subsystem in Windows that is open to both kernel-mode as well as user-mode applications. These include database systems, OLTP systems, messaging clients, and network event management systems for creating and sharing transaction logs.
In a write-up, Mandiant researchers stated that file format is not widely used or documented, and because of that, there are no tools that can parse CLFS log files. This allows the attackers to hide their data as log records conveniently, as these are accessible via API functions.
PRIVATELOG and STASHLOG are equipped with the skills that avoid the detection of malicious software, enabling it to linger on victimized devices. This includes the use of complicated strings and control flow practices that make static analysis cumbersome. Along with this, the STASHLOG installer receives a next-stage payload as an argument, where its contents are hidden in a CLFS log file.
PRIVATELOG, on the other hand, leverages a tactic called DLL search order hijacking to stack the infected library when it is called by a targeted program.
The researchers also pointed out that before using it to decrypt and save the payload, PRIVATELOG starts by counting *.BLF files in the default user’s profile directory. It then utilizes the .BLF file, which has the oldest creation date timestamp.
In order to stay vigilant, Mandiant advises organizations to apply YARA rules to examine internal networks for any indication of malware and keep an eye on potential Indicators of Compromise (IoCs) in events such as “process”, “imageload,” or “filewrite” that are linked to EDR system logs.
