Cybercriminals are hiding second-stage malware payloads in Common Log File System (CLFS) files as a means to avoid detection, taking advantage of a new storage mechanism whose inner workings are not well known by security researchers.
FireEye’s Mandiant Advanced Practices team reported their discovery of the scheme, which involves a new malware called Privatelog and its corresponding installer, Stashlog. These two malwares hide malicious code in registry transaction files by abusing CLFS, which is a Microsoft log framework that provides applications with API functions to enable the creation, storage and viewing of log data.
The adversaries behind this campaign are capitalizing on the fact that the CLFS master and container file formats are “not widely used or documented,” and “there are no available tools that can parse CLFS log files,” according to a recent FireEye blog post.
“No one in security really knows the exact structure of these files except Microsoft, so this makes it a dangerous hiding place to deliver malware while avoiding detection,” said Matthew Dunwoody, senior principal researcher, advanced practices at Mandiant, in an interview with SC Media.
The blog post said the Privatelog campaign works similarly to malware “which may rely, for example, on the Windows Registry or NTFS Extended Attributes to hide their data, which also provide locations to store and retrieve binary data with the Windows API.” Dunwoody also cited the Common Information Model (CIM) repository as another abused storage location, “but this one is new in our experience.”
“If defenders aren’t aware of this technique, they may not be able to effectively locate the hidden data or fully respond to the activity. These fileless techniques can also complicate scanning by anti-virus tools, as the storage location may not be scanned, or the storage technique may change the format of the data,” said Dunwoody, warning that attackers in the future will likely find additional storage locations to abuse, “and it will be important that we identify those new locations.”
“This discovery shows that threat actors are always on the lookup for obscure haystacks to hide needles in,” said John Bambenek, threat intelligence advisor at Netenrich. “The problem with any log file is that the amount of data is often too large for any real attempt at manual examination. Often, SIEMs are little more than digital dumpsters to check the compliance ‘centralized logging’ box. As most detection is designed around to find specific ‘badness,’ many analysts overlook non-normal log entries.”
“Log files represent fertile ground for attacking data on systems and networks,” agreed Saryu Nayyar, CEO at Gurucul. “Few organizations study their log files to better understand their computing environments, so they mostly just sit there. In this case, the CLFS log format doesn’t even have any tools available to be able to read it, so what better a place to store hacker data?”
Mandiant has not spotted any Privatelog attacks in the wild yet, which means that the malware is either still in a development phase, the work of a researcher, or being used sparingly for targeted attacks. But in case this novel attack technique becomes more commonplace, there are at least a few steps user organizations can take to prepare.
For starters, Mandiant recommends static hunting with Yara rules, and also seeking out indicators of compromise in “process”, “imageload” or “filewrite” events of EDR logs.
In the future, it may be possible that someone will develop an automated took to look for CLFS log file tampering and abuse, but first “the format would need to be analyzed and understood before a tool could be built,” said Dunwoody.
“When looking for malware, you need to know where to look for it, and this isn't an area that the industry looked at because no one knew you could store binary data in CLFS logs,” Dunwoody continued. “Now that we know this is an area that we need to search for potential dangers, we – and likely the rest of the security community – will begin tailoring solutions to address this.”
As for the CLFS framework itself, Dunwoody said that it “is part of Windows and users shouldn’t try to disable it.”
“As this behavior hasn’t been observed in the wild yet, I wouldn’t make any logging infrastructure changes beyond using the hunting indicators given by FireEye yet,” agreed Bambenek. However, “organizations can and should pay attention to SIEM log parsing errors, as this could indicate non-normal information being in the log files that may indicate similar file or data hiding techniques.”
On the other hand, Nayyar recommended a more aggressive strategy. “The easy answer to this type of attack is that if you’re not using the log data, don’t log it. Turn off logging,” said Nayyar. “If you insist on logging, examine the log files on a regular basis to ensure they haven’t been corrupted. Note when data is written into them and keep track of how that data is accessed.”
The Mandiant post also reported that both Privatelog and Stashlog use an obfuscation technique that involves “XOR’ing each byte with a hard-coded byte inline, with no loops,” such that “each string is… encrypted with a unique byte stream. Additionally, the installer Stashlog’s code is shielded with “various control flow obfuscation techniques” designed to trip up static analysis.
