The $MFT, $J, $LogFile, $T, and $I30 are all important components of the NTFS (New Technology File System) file system used in Windows operating systems. $MFT (Master File Table): Purpose: The $MFT, or Master File Table, serves as the central repository of metadata for all files and directories on an NTFS volume. It contains information such as file names, attributes, security descriptors, and data extents. Structure: The $MFT is organized as a table consisting of fixed-size entries, with each entry representing a file, directory, or metadata object. Each entry has a unique identifier known as the MFT Record Number (also called the Inode Number). Location: The $MFT is located at a fixed position near the beginning of the volume. It is crucial for the proper functioning of the file system and is allocated a portion of disk space during volume formatting. $J (Journal): Purpose: The $J, or journal, is an extension of the $LogFile and serves a similar purpose in maintaining the integrity of the file system. It records metadata changes made to files and directories, ensuring consistency in the event of system failures. Functionality: Like the $LogFile, the $J logs transactions to facilitate recovery in case of system crashes or unexpected shutdowns. However, the $J provides additional capabilities, such as journaling data changes at the cluster level, for more efficient recovery and reduced risk of data corruption. Location: The $J is typically located near the beginning of the volume, operating in conjunction with the $LogFile to provide comprehensive transaction logging and recovery capabilities. $LogFile: Purpose: The $LogFile maintains a record of transactions performed on the file system, ensuring the integrity and consistency of data. It logs changes before they are committed, allowing for recovery in case of system crashes or failures. Functionality: Whenever a modification is made to the file system, such as creating, deleting, or modifying a file, the operation is first logged in the $LogFile. This logged information can be used to reconstruct the file system state and recover data. Redundancy: To prevent data loss, the $LogFile maintains redundant copies of critical information, enabling recovery even if the primary log becomes corrupted. $T (Transaction): Purpose: The $T, or transaction metadata file, is part of the transactional NTFS feature introduced in Windows Vista and later versions. It stores metadata related to transactions, which are units of work performed on the file system. Functionality: The $T file maintains information about transactions, such as transaction IDs, transaction state, and changes made during each transaction. This facilitates atomicity, consistency, isolation, and durability (ACID properties) in file system operations. Location: The $T file is typically located in the root directory of the volume and is associated with the transactional NTFS feature. $I30 (Index Allocation): Purpose: The $I30 is an index allocation attribute used to store directory entries within a directory. It contains information about files and subdirectories, facilitating efficient directory traversal and file access. Functionality: Each directory on an NTFS volume typically has an associated $I30 attribute, which stores references to files and subdirectories contained within that directory. This index allows for quick lookup and retrieval of directory entries. Location: The $I30 attribute is part of the metadata associated with directories and is stored within the MFT entry corresponding to the directory. Summary: $MFT: Central repository of metadata for files and directories. $J (Journal): Extension of the $LogFile for logging metadata changes and ensuring file system integrity. $LogFile: Maintains a record of transactions to facilitate recovery in case of system crashes or failures. $T (Transaction): Stores metadata related to transactions for ensuring ACID properties in file system operations. $I30: Index allocation attribute used to store directory entries within directories, facilitating efficient file access and directory traversal. Akash Patel

In the realm of digital forensics, dissecting the intricacies of file systems is essential for uncovering valuable evidence and insights. One powerful tool for this purpose is The Sleuth Kit, which offers a range of utilities designed to analyze file system metadata. Understanding istat: "Istat" is a versatile tool within The Sleuth Kit that specializes in parsing metadata information from various file systems, including NTFS, FAT, and ExFAT. It can be used with forensic image files such as raw, E01, and even virtual hard drive formats like VMDK and VHD. Additionally, istat is capable of analyzing live file systems, providing forensic analysts with flexibility in their investigations. https://www.sleuthkit.org/sleuthkit/download.php Usage Example: To demonstrate the usage of istat, we want to analyze the root directory of the C: drive on a Windows system In an Administrator command prompt, we would execute the command: Command :- istat \\.\C: 5 Here, "5" represents the MFT record number reserved for the root of the volume. Command Line Options: Istat offers several optional switches to customize its behavior. "-z," which allows specifying the time zone of the image being analyzed. By default, the local time zone of the analysis system is used, but this can be overridden with the -z flag. "-s," which enables correcting clock skew in the system. This option is particularly helpful when dealing with systems that may have inaccurate time settings. MFT Entry Header: Allocation Status: Indicates whether the MFT entry is currently allocated or unallocated. File Allocation: In this instance, the directory is allocated, signifying that it's actively in use. MFT Entry Number: Each MFT entry is assigned a unique number for identification purposes. $LogFile Sequence Number: This value denotes the sequence number associated with the transactional logging information stored in the $LogFile. $STANDARD_INFORMATION Attribute: Purpose: This attribute stores essential metadata about a file, providing crucial details for file management and access control. Contents: Timestamps: Four timestamps are typically included: Created: Indicates when the file was originally created. Modified: Reflects the last time the file's contents were modified. MFT Entry Modified: Represents the last modification time of the MFT entry itself. Last Accessed: Records the last time the file was accessed. File Attributes: Flags indicating various properties of the file, such as read-only, hidden, system file, etc. Security Information: Permissions and access control settings associated with the file. USN Journal Sequence Number: Used for tracking changes to the file for journaling and auditing purposes. $FILE_NAME Attribute: Purpose: This attribute contains information about the file's name, location, and other related details. File Name: The primary name of the file. File Namespace: Indicates the namespace in which the file resides (e.g., NTFS, POSIX). Parent Directory: Information about the directory where the file is located. File Attributes: Similar to those in the $STANDARD_INFORMATION attribute, indicating properties like read-only, hidden, system file, etc. Timestamps: Typically includes timestamps for creation, modification, and last access. Hard Link Count: Specifies the number of hard links associated with the file. File Reference Number: Unique identifier for the file within the file system. Security Descriptor: Security-related information such as permissions and access control settings. Relationship: The $STANDARD_INFORMATION attribute provides general metadata about the file, including timestamps and security information. The $FILE_NAME attribute complements this by providing specific details about the file's name, location, and attributes. Conclusion: Understanding the motives behind timestamp modification, both legitimate and malicious, is crucial for effective forensic analysis and system security. By employing diverse detection methods and leveraging forensic tools, analysts can identify potential timestamp anomalies and uncover malicious activity, enhancing system defense and threat mitigation efforts.

Plaso is the Python-based backend engine powering log2timeline, while log2timeline is the tool we use to extract timestamps and forensic artifacts. Together, they create what we call a super timeline—a comprehensive chronological record of system activity. Super timelines, unlike file system timelines, include a broad range of data beyond just file metadata. They can incorporate Windows event logs, prefetch data, shell bags, link files, and numerous other forensic artifacts. This comprehensive approach provides a more holistic view of system activity, making it invaluable for forensic investigations. Example: Imagine you've been given a disk image, perhaps a full disk image or a image created with KAPE. Your task: find evil, armed with little more than a date and time when the supposed activity occurred. So, you begin the investigation with the usual suspects: examining Windows event logs, prefetch data, various registry-based artifacts, and more. But after a while, you realize that combing through all these artifacts manually will take forever. Wouldn't it be great if there was a tool that could parse all these artifacts, consolidate them into a single data source, and arrange them in chronological order? Well, that's precisely what we can achieve with Plaso and log2timeline. I am going to use Ubuntu 22.04LTS version(Virtual box) and Plaso version 20220724 Installation: https://plaso.readthedocs.io/en/latest/sources/user/Ubuntu-Packaged-Release.html Lets start: We need image or collected artifact: The data we're dealing with could take various forms—it might be a raw disk image, an E01 image, a specific partition or offset within an image, or even a physical device like /dev/sdd. Moreover, it could manifest as a live mount point; for instance, we could mount a VHDX image created with KAPE and direct the tool to that mount point. With such versatility, we're equipped with a plethora of choices, each tailored to the specific nature of the data at hand. In current case I did capture the image using Kape tool and then I mounted the image in form of drive in my windows host than I shared the Mounted drive to (Ubuntu) virtual box If you are not able to access the mounted drive in ubuntu you have to enter below in terminal Command :- sudo adduser $USER vboxsf than restart the VM 2. Command and output (Syntax) Syntax log2timeline.py --storage-file OUTPUT INPUT and command will be like in our case log2timeline.py --storage-file akash.dump /media/sf_E_DRIVE akash.dump -- output file name which will be created (this will be in SQL format) you can add path like /path-to/akash.dump /media/sf_E_DRIVE -- Mounted drive path (1) Raw Image log2timeline.py /path-to/plaso.dump /path-to/image.dd (2) EWF Image log2timeline.py /path-to/plaso.dump /path-to/image.E01 (3) Physical Device log2timeline.py /path-to/plaso.dump /dev/sdd (4) Volume via Sector Offset log2timeline.py -o 63 /path-to/plaso.dump /path-to/image.dd 3. if you have entire image of drive as a artifact. log2timeline can ask to provide the which partition or vss you want to parse. if log2time find VSS. it will as for which vss as well You can mention identifier either one vss or all. Example :- 1 or 1..4 or all or (Single command) log2timeline.py --partitions 2 --vss-stores all --storage-file /path-to/plaso.dump /path- to/image.dd Now in current case I don’t have VSS or partition because I collected only needed artifacts (not entire drive) so in this case I did not get above options you can see screen shot below what it looks like once you hit enter. You can also use Parsers and filters against image with plaso/log2timeline and store in akash.dump or any output.dump file Parsers:- which will help us tell log to timeline to concentrate only on certain specific forensic artifacts To check all available parsers: log2timeline.py --parsers list |more if you want to use particular parser: In current case log2timeline.py --parsers windows_services --storage-file akash2.dump /media/sf_E_DRIVE you can write your own parsers: https://plaso.readthedocs.io/en/latest/sources/developer/How-to-write-a-parser.html 2. Filters: - Filter will tell logged timeline to go after specific files that would contain forensically valuable data like /users /windows/system32 Now there is txt file containing all important filter you can parse from image. Link below https://github.com/mark-hallman/plaso_filters/blob/master/filter_windows.txt you can do is open link and click on raw copy the link in ubuntu write : wget https://raw.githubusercontent.com/markhallman/plaso_filters/master/filter_windows.txt it will save the txt file after saving text file you can run below command Command log2timeline.py -f filter_windows.txt --storage-file akash2.dump /media/sf_E_DRIVE What this command will do from image it will go to specific files /Paths which are mentioned in txt file and capture artifact into akash2.dump file you can combine parser and filter in same command as well log2timeline.py - -parsers webhist -f filter_windows.txt --storage-file akash2.dump /media/sf_E_DRIVE what i am telling timeline to do is to target the paths and locations within the filter file and then against those particular locations run the web hist parser which will parse our browser forensics artifacts Now after all the command you will get output in output.dump or in my case akash.dump file. output will be in sql format and its very difficult to understand so now you have convert this dump file into csv format or any format which you prefer (I prefer CSV format because i will use timeline explorer to analyze further) 1. Using pinfo.py As the name suggests, it furnishes details about a specific Plazo storage file (output file): In our case for akash.dump Command pinfo.py akash.dump 2. Using psort.py this command is for Which format you want to create output. Command :- psort.py --output-time-zone utc -o list Now to analyze output with timeline_explorer from eric Zimmerman we will use  l2tcsv format Complete command :- psort.py --output-time-zone utc -o l2tcsv -w timeline.csv akash.dump -w write format "Within an investigation, it's common to have a sense of the time range in which the suspected incident occurred. For instance, let's say we want to focus on a specific day and even a particular time within that day—let's choose February 29th at 15:00. We can achieve this using a technique called slicing. By default, it offers a five-minute window before and after the given time, although this window size can be adjusted." Command : psort.py --output-time-zone utc -o l2tcsv -w timeline.csv akash.dump - - slice '2024-02-29 15:00' "However, use a start and end date to delineate the investigation timeframe. This is achieved by specifying a range bounded by two dates. For example, "date > '2024-12-31 23:59:59' and date < '2020-04-01 00:00:00'." Command : psort.py --output-time-zone utc -o l2tcsv -w timeline.csv akash.dump "date > '2024-12-31 23:59:59' AND date < '2024-04-01 00:00:00'" Once super timeline is create in CSV format. We can use timeline explorer to analyze. The best part of timeline explorer is Data loaded into Timeline Explorer is automatically color-coded based on the type of artifact. For example, USB device utilization is highlighted in blue, file openings in green, and program executions in red. This color-coding helps users quickly identify and interpret different types of activities within the timeline. Recommended column to look while analyzing: Date, Time, MACB, Source type, desc, filename, inode, notes, extra Conclusion: In conclusion, Plaso/Log2Timeline stands as a cornerstone in the field of digital forensics, offering investigators a powerful tool for extracting, organizing, and analyzing digital evidence. Its origins rooted in the need for efficiency and accuracy, coupled with its continuous evolution and updates, make it an essential asset for forensic practitioners worldwide. As digital investigations continue to evolve, Plaso/Log2Timeline remains at the forefront, empowering investigators to unravel complex digital mysteries with ease and precision.

Lets understand with example: We have created table to understand NTFS Operations 1. Create Operation: When a file is created, according to the table, all timestamps (Modified, Accessed, Created) are updated 2. Modify Operation: When a file is modified, only the Modified timestamp is expected to change, while the Accessed and Created timestamps remain unchanged. However, if NtfsDisableLastAccessUpdate is enabled (set to 0), the Access timestamp will be updated along with the Modified timestamp. In this case its enabled: 3. Copy Operation: When a file is copied using Windows Explorer, the Modified timestamp of the new file inherits from the original file, while the Created and Accessed timestamps are updated to the current time. If a file is copied using the command line (cmd), the behavior is similar to using Windows Explorer. Both methods update the Created and Accessed timestamps of the copied file. However: But when we analyze $MFT File. We may actually see a difference. Because MFT will show us all the time stamps ($SI)These time stamps are which accessible by windows API ($FN) These time  stamps are accessible by Windows kernel 4. File Access: The behavior of the Access timestamp depends on the NtfsDisableLastAccessUpdate registry setting. If enabled, the Access timestamp will be updated upon file access. -------------------------------------------------------------------------------------------------------------

Introduction DensityScout, a robust tool crafted by Christian Wojner at CERT Austria, stands at the forefront of digital forensics and cybersecurity. Specializing in the detection of common obfuscation techniques such as runtime packing and encryption, DensityScout has become an invaluable asset for security professionals seeking to identify and neutralize potential threats. Decoding Density: A Measure of Randomness At the heart of DensityScout lies the concept of "density," which serves as a measure of randomness or entropy within a file. In straightforward terms, files exhibiting encryption, compression, or packing tend to possess a higher degree of inherent randomness, setting them apart from their normal counterparts. Legitimate executables in Windows, known for their lack of packing or encryption, rarely display random character sequences, leading to higher entropy. Understanding the DensityScout Command The command-line operation of DensityScout provides users with a powerful and customizable approach to file analysis. A typical command, such as Command :- densityscout.exe-pe -r -p 0.1 -o results.txt c:\Windows\System32 exemplifies the tool's capabilities. -pe Option: Instructs DensityScout to select files using the well-known signature of portable executables ("MZ"), transcending conventional file selection by extension. This is instrumental in identifying executable files that may have been strategically renamed to evade detection. -r Flag: Directs the tool to perform a recursive scan of all files and sub-folders from the specified starting point, ensuring a comprehensive examination. -p 0.1 Option: Allows users to set a density threshold for real-time display during the scan. Files with a density below the provided threshold (0.1 in this example) are promptly revealed on the screen. This option caters to users who prefer immediate insights rather than waiting for the entire scan to conclude. -o results.txt Option: Specifies the output file where DensityScout records the density values for each evaluated file. This file becomes a valuable resource for analyzing and further investigating findings. Interpreting Density Values Understanding the significance of density values is crucial in leveraging DensityScout effectively. A density value less than 0.1 often indicates a packed file, signifying a higher degree of randomness. Conversely, normal files, especially those typical of Windows executables, tend to have a density greater than 0.9. Real-world Application and Use Cases DensityScout has proven its mettle in real-world scenarios, providing security professionals with actionable insights into potentially malicious files. The tool's ability to promptly reveal files with suspicious densities ensures a proactive approach to threat detection. Next Steps As you delve into the world of digital forensics and cybersecurity, consider incorporating DensityScout into your toolkit. Explore the tool's capabilities, experiment with different parameters, and enhance your ability to identify and neutralize suspicious files. Final Thoughts In the pursuit of securing digital environments, tools that decode the intricacies of file structures become indispensable. DensityScout's focus on "density" adds a pragmatic layer to file analysis, contributing significantly to the collective efforts of cybersecurity professionals worldwide. Tool Link:- https://cert.at/en/downloads/software/software-densityscout Akash Patel

Introduction: KAPE, crafted by Eric Zimmerman, stands as a powerful, free, and versatile triage collection and post-processing tool designed to streamline forensic data gathering. It operates seamlessly with crowd-sourced "target" files, enabling the identification and collection of specific artifacts. Let's delve into the intricacies of this exceptional tool. Key Features: 1 . Meta-Files for Artifacts: KAPE utilizes "target" files grouped into meta-files, such as the "!SANS Triage.tkape," covering artifacts from SANS FOR498, FOR500, and FOR508 classes. Currently Windows-exclusive, KAPE can be executed from a thumb drive or remotely downloaded/pushed to a system. Results can be directed to an attached drive, file share, SFTP server, or cloud platforms like Amazon AWS or Microsoft Azure. SANS instructors have ingeniously employed PowerShell remoting for endpoints to download and run KAPE in batch mode, sending data to an SFTP server in the cloud. Capabilities: 1 . Artifact Collection: KAPE's capabilities extend to collecting virtually any forensic artifact needed, offering a rapid and reliable process. Portable with no installation requirements, KAPE boasts detailed audit logging for meticulous tracking. The tool is flexible and customizable, overcoming wildcard and recursion challenges in other tools. It enables easy standardization of collected data across teams. KAPE excels in collecting locked system files, alternate data streams, and even supports extraction from Windows Volume Shadow Copies. The tool is exceptionally fast, incorporating inline de-duplication to reduce collection sizes effectively. KAPE supports post-processing of collected data through module capabilities, enhancing its overall utility. Example Command Line: kape.exe --tsource F --target !SANS_Triage --tdest C:\temp\Output Explanation: --tsource: Specifies the drive or directory to search (e.g., F). --target: Identifies the target configuration or meta-file to run. --tdest: Specifies the directory to store copied files. Additional Options: vss: Enables the search on all available Volume Shadow Copies on --tsource. vhdx and vhd: Creates a VHDX virtual hard drive from the contents of --tdest. debug: Enables debug messages when set to true. Conclusion: KAPE emerges as an indispensable tool in the forensic arsenal, offering a user-friendly yet powerful approach to artifact collection and post-processing. Its efficiency, coupled with extensive customization options, positions it as a go-to solution for forensic practitioners worldwide. Akash Patel

In this blog post, we will delve into the significance of detecting WMI-based attacks and explore techniques to defend against them. Command Line Auditing: A Game-Changer The absence of command line auditing in an enterprise is akin to being blind to the majority of WMI-based attacks. In the absence of this critical tool, identifying malicious activities becomes an arduous task, requiring exhaustive efforts in traditional forensics. Fortunately, modern solutions like Microsoft Sysinternals' Sysmon and advanced endpoint detection and response tools offer the ability to record command lines, ensuring comprehensive coverage against stealthy WMI attacks. Microsoft Sysmon: A Shield Against WMI Threats Sysmon, a free Sysinternals tool, emerges as a formidable ally in the battle against WMI threats. Tailored for detecting malicious activities, Sysmon provides detailed logs without overwhelming collection capabilities. Its integration with command line auditing equips organizations with the visibility needed to identify and neutralize potential threats promptly. Link: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon Unveiling WMI Event Consumers: Understanding the anatomy of WMI event consumers is paramount for effective defense. PowerShell commands to collect information about WMI event filters, consumers, and bindings are showcased, providing a blueprint for organizations to proactively identify and thwart potential threats. Best practices, such as querying both standard and non-standard namespaces, are explored to stay one step ahead of evolving attack techniques. PowerShell Commands for WMI Event Consumer Collection: Get-WMIObject -Namespace root\Subscription -Class __EventFilter Get-WMIObject -Namespace root\Subscription -Class __EventConsumer Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding Get-WMIObject -Namespace root\Default -Class __EventFilter Get-WMIObject -Namespace root\Default -Class __EventConsumer Get-WMIObject -Namespace root\Default -Class __FilterToConsumerBinding Scaling Defense with PowerShell Remoting: While auditing WMI event consumers on a single system is crucial, the real challenge lies in scaling defense across multiple systems. PowerShell remoting allows organizations to collect comprehensive data, which can be analyzed through databases like ELK stack or Splunk. PowerShell Command for Remote WMI Event Consumer Collection: # Read computer names from a text file $ComputerNamesFile = "C:\Path\To\Your\ComputerNames.txt" $RemoteComputers = Get-Content $ComputerNamesFile $Credentials = Get-Credential $ScriptBlock = { Get-WMIObject -Namespace root\Subscription -Class __EventFilter Get-WMIObject -Namespace root\Subscription -Class __EventConsumer Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding } # Invoke the script block on remote computers Invoke-Command -ComputerName $RemoteComputers -ScriptBlock $ScriptBlock -Credential $Credentials Ensure that your text file (ComputerNames.txt) contains one computer name per line. Modify the path in $ComputerNamesFile to point to the actual location of your text file. Conclusion: Implementing robust command line auditing, leveraging tools like Sysmon, and embracing PowerShell for detection are critical steps in fortifying defenses against stealthy WMI threats. By understanding the dual nature of WMI and PowerShell, organizations can turn these tools into powerful allies in the ongoing battle for cybersecurity. Stay vigilant, stay secure! Akash Patel

In my upcoming blog series, we'll embark on a journey to unravel the complexities surrounding credential theft, exploring various attack vectors and, more importantly, delving into effective defense strategies. Compromising Credentials Post 1: Hashes - Unveiling the Silent Guardians Post 2: Tokens - Navigating the Identity Gateway Post 3: Cached Credentials - A Double-Edged Sword Post 4: LSA Secrets - Fortifying System Integrity Post 5: Tickets - The Unauthorized Access Keys Post 6: NTDS.DIT - Safeguarding the System Core Join me in this comprehensive exploration of credential theft, where knowledge is power, and proactive defense is the key to a resilient cybersecurity posture. Stay tuned for valuable insights and practical tips to safeguard your digital identity. Akash Patel

This blog series aims to dissect various techniques employed by malicious actors to maintain a lasting presence on compromised systems. Over the next few posts, we will delve deeper into each method, providing comprehensive insights into detection, prevention, and mitigation strategies. Malware Persistence Mechanisms AutoStart Locations Service Creation/Replacement Service Failure Recovery Scheduled Tasks DLL Hijacking WMI Event Consumers Local Group Policy, MS Office Add-In, or BIOS Flashing Conclusion: Stay tuned as we navigate through the intricacies of each malware persistence method. By gaining a deeper understanding of these techniques, defenders can enhance their ability to detect, prevent, and mitigate persistent threats in the evolving landscape of cybersecurity. Akash Patel

In this blog, we delve into effective threat hunting strategies to uncover and counter malicious WMI activity, emphasizing the importance of staying ahead of the adversary. Understanding the Threat: WMI attacks have become a favorite among threat actors due to their versatility and the inherent trust placed in WMI processes by the Windows operating system. To effectively counter these threats, cybersecurity professionals must familiarize themselves with common attack tools and scripts employed by malicious actors. Hunting Techniques: Command Line Auditing: Implementing command line auditing is a crucial capability for monitoring WMI activity. By tracking command line executions, defenders can identify anomalous patterns and potential malicious activity. This proactive approach enhances the ability to detect and respond to WMI attacks. In-Memory Analysis: Analyzing processes in memory provides a dynamic perspective on WMI activity. Process trees and in-memory analysis can reveal patterns such as 'wmiprvse.exe' with unusual parent or child processes, highlighting potential indicators of compromise. Threat hunters should leverage in-memory forensics to level the playing field against sophisticated adversaries. Logging and Auditing WMI Repository: Regular logging and auditing of the WMI repository for event consumers are essential. Monitoring for changes in event consumers, especially those triggered by suspicious scripts like PowerShell or encoded command lines, can uncover attempts at persistence and privilege escalation. File System Residue Analysis: Examining the file system residue of tools like 'mofcomp.exe' provides insights into potential malicious activities. The residue left behind in directories or 'AutoRecover' folders, especially when coupled with the presence of '#PRAGMA AUTORECOVER' in MOF files, can serve as valuable artifacts for forensic analysis. Suspicious Patterns to Look For: wmic process call create /node: Detection of this command may indicate attempts to execute processes remotely, potentially a red flag for malicious activity. Invoke-WmiMethod / Invoke-CimMethod (PowerShell): Monitoring PowerShell commands invoking WMI methods can uncover sophisticated attacks. Threat hunters should be vigilant for encoded command lines and unusual PowerShell activity. wmiprvse.exe Anomalies: Keep an eye out for instances where 'wmiprvse.exe' has unusual parent processes (not 'svchost.exe') or abnormal children processes (e.g., 'powershell.exe'). These anomalies could signify malicious intent. scrcons.exe (ActiveScript Consumer): The presence of 'scrcons.exe,' an ActiveScript Consumer, is a potential indicator of malicious behavior. ActiveScript events, especially when tied to suspicious scripts, warrant thorough investigation. Conclusion: As cyber threats continue to advance, threat hunters play a pivotal role in fortifying defenses. By staying informed about the latest attack tools, employing command line auditing, leveraging in-memory analysis, and scrutinizing WMI repositories, defenders can proactively identify and neutralize malicious WMI activity. The blog concludes with a reminder that WMI is inherently stealthy, emphasizing the need for continuous learning and the development of effective threat hunting strategies to stay one step ahead of adversaries. Akash Patel

This blog explores the significance of a specific attribute within MOF files – “#PRAGMA AUTORECOVER” – shedding light on its forensic implications and the motivations behind its inclusion in malicious payloads. Understanding #PRAGMA AUTORECOVER: #PRAGMA AUTORECOVER primary purpose is to safeguard against potential data loss within the WMI repository. When this pragma is included, a copy of the MOF file is stored, ensuring that even if the WMI repository needs to rebuild itself, the original entries do not age out. Forensic Artifacts and Detection: In instances where #PRAGMA AUTORECOVER is part of a malicious MOF file, remnants of the file can be found within the "C:\Windows\System32\wbem\AutoRecover" This presents a valuable opportunity for cybersecurity professionals to identify and analyze potentially harmful introductions in the WMI database. The autorecover feature can also be triggered using the mofcomp.exe tool with the "-autorecover" parameter. Analyzing the AutoRecover Folder: Upon inspection of the "AutoRecover" folder, analysts may encounter renamed copies of MOF files, each containing a textual representation of the original entries. Although the original filename may not be evident, the timestamps (creation and modification) can be instrumental in identifying outliers. The presence of these files in the expected time range of an attack becomes a crucial indicator for further investigation. Windows Registry Entry: When #PRAGMA AUTORECOVER is utilized, a corresponding Windows Registry entry is generated in the "HKLM\SOFTWARE\Microsoft\Wbem\CIMOM" Under the "Autorecover MOFs" value, the recorded name includes the folder path where it existed during compilation. This information, coupled with the type of consumer (e.g., "ActiveScript"), serves as a valuable clue for investigators to scrutinize the AutoRecover folder files on disk. Motivations Behind #PRAGMA AUTORECOVER in Malicious MOF Files: The prevalence of #PRAGMA AUTORECOVER in malicious MOF files raises questions about the motives of threat actors. Ignorance of detection risks, combined with a desire to maintain persistence within compromised networks, likely drives the inclusion of this pragma. Considering that MOF files primarily serve the purpose of persistence, they become a crucial avenue for threat actors to regain access to compromised systems. Conclusion: As cybersecurity professionals strive to stay ahead of evolving threats, understanding the nuances of techniques employed by threat actors is paramount. The exploration of #PRAGMA AUTORECOVER within malicious MOF files emphasizes the importance of proactive detection, analysis, and mitigation strategies. Akash Patel

Understanding MOF Files: MOF(Managed Object Format) files act as blueprints for WMI, representing class definitions and instances. Windows utilizes these files to build and maintain the WMI repository, with every aspect of the repository initially defined in a MOF. While originally designed for legitimate system operations, MOF files have become a prevalent vehicle for introducing malicious classes into the WMI repository. Challenges in MOF File Detection: The challenge in detecting malicious MOF files lies in their flexibility and stealth. These files can be stored anywhere, named arbitrarily, and even deleted after introduction into the WMI repository. Normally References to MOF files can be found in the WMI binary tree index, Command:- C:\Windows\System32\wbem\Repository\index.btr Remote Namespace Complications: Adding a layer of complexity, the MOF compiler allows for remote namespace compilation. By supplying the "-N" switch with a remote machine name and MOF file, threat actors can compile and insert new classes into a remote system's WMI database without leaving the file on the target system. This evasion tactic highlights the importance of collecting command lines for comprehensive threat detection. Command:- mofcomp -N \\[machinename]\root\subscription test.mof PowerShell as a Silent Weapon: MOF files are not the exclusive means for setting up WMI consumers. Threat actors can leverage PowerShell to directly insert WMI object definitions into the Common Information Model (CIM) repository. This method, although leaving fewer artifacts, underscores the need for a holistic approach to cybersecurity, including advanced threat detection mechanisms. Example: The Stuxnet Conundrum: Exploring the historical context, the infamous Stuxnet worm, known as the "King of WMI Event Consumers," opted for the mofcomp.exe route. At its deployment, security measures were not attuned to detect this type of attack. Stuxnet's use of a zero-day exploit that allowed writing arbitrary files justified the choice of mofcomp.exe over PowerShell. PowerShell Sample for Database Manipulation: A PowerShell sample demonstrates how threat actors can set up a CommandLineEventConsumer without a MOF file. The script includes commands to create an EventFilter, CommandLineEventConsumer, and FilterToConsumerBinding, showcasing the simplicity and effectiveness of this technique: # Set up EventFilter Set-WmiInstance -Class EventFilter -Namespace "root\subscription" -Arguments @{ Name = "wmi" EventNameSpace = "root\cimv2" QueryLanguage = "WQL" Query = "SELECT * FROM InstanceModificationEvent WITHIN 10 WHERE TargetInstance ISA 'Win32_Service'" } # Set up CommandLineEventConsumer Set-WmiInstance -Class CommandLineEventConsumer -Namespace "root\subscription" -Arguments @{ Name = "wmi" ExecutablePath = 'C:\alg.exe' CommandLineTemplate = 'C:\alg.exe' } # Set up FilterToConsumerBinding Set-WmiInstance -Class FilterToConsumerBinding -Namespace "root\subscription" -Arguments @{ Filter = "wmi" Consumer = "wmi" } Conclusion: MOF files, once a foundational element for WMI functionality, have evolved into a potential vector for stealthy malicious activities. Understanding their role, challenges in detection, and the diversification of attack techniques, including PowerShell-based methods, is crucial for building robust defenses against sophisticated cyber threats. Cybersecurity professionals must adapt to the dynamic landscape, employing a proactive approach to safeguard systems against evolving attack vectors. Akash Patel