Dell SecureWorks Counter Threat Unit™ (CTU) researchers unearthed a novel persistence implementation that employed anti-forensics techniques to avoid discovery.
CTU researchers analyzed a Windows 2003 server that was involved in a ransomware incident. Detailed forensic analysis of the image acquired from the system indicated that the threat actor likely had access to the system for a considerable time. Available data showed indications of activity going back almost 2.5 years.
As part of the analysis process, CTU researchers created a timeline of system activity using several data sources from the system image. The timeline excerpt in Figure 1 shows the installation of a persistence mechanism. The primary indicator of interest is the registry key named “Win32ClockProvider.” As described by Mandiant (now FireEye) analysts in a 2014 presentation, this indicator, particularly when associated with other relevant indicators, could be the result of threat actors using Windows Management Instrumentation (WMI) to create persistence for something (a script, an executable, etc.) on the system that is launched on a time trigger.
Figure 1. Timeline excerpt. (Source: Dell SecureWorks)
Other information captured in the timeline (e.g., references to \wbem\mof\ and the mofcomp.log file) appears to support this finding. Figure 2 shows relevant log entries from the mofcomp.log file.
Figure 2. Mofcomp.log entries. (Source: Dell SecureWorks)
CTU researchers retrieved the iisstt.dat, 15.log, and OBJECTS.DATA files from the system image and analyzed them using a set of proprietary tools developed by the CTU research team specifically to detect and report WMI persistence mechanisms. When the tools produced no results, CTU researchers applied a more direct, manual analysis process and determined that the threat actor had employed forensic countermeasures to avoid detection. First, the files used to implement the persistence mechanism (iisstt.dat and 15.log) did not contain text-based Managed Object Format (MOF) content typically used to create new entries in the WMI Web-Based Enterprise Management (WBEM) database. Instead, they were binary data files that were not human-readable. In addition, CTU researchers determined that the programmer of the Visual Basic script embedded within the WBEM database reimplemented the ActiveScriptEventConsumer class as a custom class to avoid being detected by automated monitoring and analysis tools and to evade analysts performing digital forensic analysis. CTU researchers used these insights to modify the proprietary WMI detection tools to detect and recover the embedded script.
The embedded Visual Basic script enables the Guest account on the system, sets a password, and then copies account information from the Administrator account to the Guest account. This script was set to run each day at 11:00 pm Eastern Time (ET), with each execution overwriting the artifacts of the previous execution. CTU researchers parsed the SAM registry file, which contains information about local user accounts on the system, to analyze the script's final execution prior to the acquisition of the system image.
Figure 3 illustrates the Guest account details at the time that the system was analyzed. The timestamps are displayed in UTC format. The account's “Pwd Reset Date,” when the password was last set, is approximately 4:00 am UTC, which corresponds to 11:00 pm ET. Although the Guest account is usually disabled by default, Figure 3 shows that this account is enabled and appears to have been used to log into the system nine times.
Figure 3. Guest account details. (Source: Dell SecureWorks)
However, this information is misleading, as the script also copies the displayed settings from the Administrator account. Figure 4 illustrates the Administrator account details at the time that the system was analyzed.
Figure 4. Administrator account details. (Source: Dell SecureWorks)
The embedded script also downloads and executes an encoded payload. The domain that hosted the payload no longer resolves to an IP address as of this publication.
The threat actor's use of binary MOF files provided an effective means of persistence and also prevented detection by antivirus applications, automated monitoring and analysis tools, and even traditional techniques used in digital forensic analysis (keyword searches, etc.). By using this well-considered approach, the threat actor demonstrated detailed knowledge of the Microsoft Windows operating system and an understanding of the digital forensic analysis and incident response techniques employed within many organizations.