Dear readers and followers, I hope this message finds you well. I wanted to take a moment to share an important update regarding our blog. Due to some unforeseen circumstances, I was not able to publish new blog posts from April 5th. Please rest assured that this pause is temporary. I am actively working to resolve the issues at hand and will be back as soon as possible with fresh and engaging topics for you to enjoy. I understand that you might be looking forward to our regular updates, and I sincerely apologize for any inconvenience this may cause. Your patience and understanding during this time are greatly appreciated. In the meantime, I encourage you to explore our archive of past blog posts. There's a wealth of information, tips, and insights waiting for you there. Thank you once again for your continued support and understanding. I look forward to reconnecting with you all very soon with new and exciting content. Stay tuned, and take care! Akash Patel

Introduction: Solid-state drives (SSDs) have revolutionized data storage with their speed, reliability, and lack of moving parts. However, their unique characteristics pose challenges for forensic investigators and analysts. Understanding SSDs: SSDs utilize non-volatile flash memory for data storage, providing faster access times and improved reliability compared to traditional hard drives. (Non-volatility allows flash SSDs to retain memory during a sudden power loss.) Limited Writes and NAND(non-volatile storage) Flash Quality: SSD reliability is directly affected by the number of writes to the NAND(non-volatile storage) flash memory. Frequent writes can lead to data corruption and reduce the lifespan of the drive. Consumer-grade SSDs often use lower quality NAND(non-volatile storage) flash, making them more susceptible to wear and tear from repeated writes. Wear Leveling: Wear leveling is a technique used to distribute write and erase cycles evenly across the SSD's memory cells. When data is modified, it is moved to a new location, and the original location is marked for erasure. This helps prevent certain memory cells from wearing out faster than others. Drive Trimming or Trim: Trim is a feature that improves SSD performance and lifespan by informing the drive which data blocks are no longer in use, allowing the SSD to reclaim them. Effects on Forensic Analysis: Wear leveling can affect forensic analysis by altering the physical location of data on the SSD, making it challenging to recover specific sectors or data remnants such as file slack. Trim operations can also impact forensic investigations by eliminating data remnants and reducing the effectiveness of traditional techniques like file carving. Prefetch and ReadyBoost: Prefetch and ReadyBoost, which are designed to improve system performance by caching frequently accessed data, may be disabled or enabled depending on the SSD configuration. Microsoft has started enabling prefetch and ReadyBoost by default on SSDs due to their improved performance, which may affect forensic analysis and investigation techniques. Acquisition of Data from SSDs: Acquiring data from SSDs requires careful consideration of power loss concerns and data collection methods: Power Loss Concerns: Cutting power to a running SSD can lead to serious problems, potentially causing data modifications during recovery processes. Traditional shutdown processes can also trigger drive optimization activities, affecting data integrity. 2. Impact on Data Collection: Cutting power to an SSD may not be the best option for ensuring proper data collection. The repair operations initiated by the SSD during power loss recovery can involve tasks such as trimming operations and wear leveling, which can affect the integrity of the data. Simply powering off the system using a normal shutdown process can also trigger drive optimization activities, further complicating data collection. 3. Live Acquisition Considerations: Some experts suggest that live imaging of the system might be the best approach for acquiring data from SSDs. Leaving the SSD running for extended periods, even in a powered-down state, can potentially corrupt the data. Live acquisition, similar to imaging memory, may offer better control over the data and reduce the risk of unintended modifications by the SSD. 4. Recommended Recovery Procedures: In case of a drive failure due to power loss, it is recommended to follow specific recovery guidelines provided by manufacturers like Crucial. The recovery process involves completing a power cycle, which may take approximately one hour. This procedure is typically performed on a laptop or desktop computer by connecting the SSD to the SATA power connector and following specific steps to power cycle the drive. Once you have the drive connected and sitting idle, simply power on the computer and wait for 20 minutes. We recommend that you don't use the computer during this process. Power the computer down and disconnect the drive from the power connector for 3 0 seconds. Reconnect the drive, and repeat steps 1 and 2 one more time. Reconnect the drive normally, and boot the computer to your operating system. If the latest firmware has not been updated to your drive, do so. 5. Write Blocking and Analysis: While write blocking drives using standard write blockers can prevent accidental writes from the connected operating system, the SSD's controller may still perform wear leveling and trimming operations when powered on. Using a write blocker for imaging purposes is recommended to preserve drive integrity, but prolonged analysis on an SSD connected via a write blocker may increase the risk of controller-initiated drive management operations, potentially compromising data integrity. Will disk defragmentation be disabled by default on SSDs? Answer: Yes, disk defragmentation is disabled by default on SSDs. This is because SSDs do not benefit from defragmentation like traditional mechanical hard drives. In fact, defragmentation can cause unnecessary wear and tear on SSDs without providing any performance improvements. Will SuperFetch be disabled on SSDs? Answer: It depends. While newer versions of Windows, such as Windows 8 and Windows 10, typically keep SuperFetch enabled on SSDs, older Windows 7 systems may disable SuperFetch if an SSD drive is detected. SuperFetch can improve system performance by preloading frequently used applications into memory, but on SSDs, it may not be as necessary due to the faster read/write speeds. Does the Windows Search Indexer operate differently on SSDs? Answer: No, the Windows Search Indexer operates the same way on SSDs as it does on traditional hard drives. The Search Indexer creates and maintains a database of file and folder information to enable quick file searches. While SSDs may have faster access times, the functionality of the Search Indexer remains unchanged. What should you do if the hash does not match on the first attempt to image an SSD? Answer: If the hash does not match on the first attempt to image an SSD, it's recommended to keep the original image and reimage the drive again. The most likely reason for the hash mismatch is due to wear leveling or trim operations occurring after the initial hash was generated. By comparing the original and subsequent images, you can identify any differences caused by wear leveling or trim, such as deleted files or changes in unallocated space. This comparison can help mitigate concerns over unmatched hashes when presenting evidence in legal proceedings. Conclusion: Solid-state drives offer numerous benefits, but their unique characteristics present challenges for forensic investigators. By understanding the behavior of SSDs, implementing proper acquisition techniques, and adhering to best practices, forensic analysts can effectively acquire and analyze data from SSDs while maintaining data integrity and reliability. Akash Patel

In today's digital age, forensic investigators face the challenge of extracting valuable evidence from various storage devices, including solid-state drives (SSDs). With techniques like datastream carving, file carving, and parsing metadata, investigators can uncover crucial information for legal proceedings and investigations. Datastream Carving vs. File Carving: 1. Datastream Carving: Involves extracting small fragments of data from larger files. Useful for recovering valuable information, such as URLs and timestamps, from partially deleted files. Tools like Magnet Forensics' Internet Evidence Finder (IEF) facilitate the process by scanning for fragments and full files across storage devices. 2. File Carving: Focuses on recovering intact files from memory or unallocated space. Scans for known file headers and carves out files based on predicted lengths or known footers. Effective for recovering specific types of deleted files but may yield numerous false positives. Parsing Metadata in Files: Metadata embedded within files provides insights into their creation, modification, and history. Microsoft Office documents and picture files contain metadata such as author information, creation time, GPS Coordination, and camera details. Example : For Microsoft Office documents, metadata may include details such as author information, creation time, last print time, and even the version of Microsoft Office used to create the document. This information can help establish the origin and authenticity of the document, which is especially important in cases involving stolen or altered documents. Similarly, picture files contain metadata, which includes information about how the picture was taken. This data typically includes the original picture creation date, the type of camera used, and even GPS coordinates if the device has a built-in GPS. Tools like exiftool can parse metadata from files, uncovering valuable information for e-discovery cases and investigations. In e-discovery cases, requesting metadata can be crucial for building a comprehensive understanding of the evidence and ensuring a fair trial. Judges often grapple with the complexities of metadata requests, recognizing its potential to make or break a case. By leveraging tools like exiftool to parse metadata from files, investigators can uncover valuable information that may strengthen their legal arguments and provide clarity in complex litigation scenarios https://exiftool.org/ Recovering Deleted Files: Forensic analysis often involves recovering lost or deleted files from storage devices. Metadata layer extraction focuses on retrieving file properties, while unallocated space extraction scans for file headers and clusters. Tools like Photorec facilitate file recovery by scanning for file headers and attempting to reconstruct fragmented files. Using Photorec: Photorec is a versatile data recovery program that reads file headers and targets various media file types. It can recover files from hard drives or mounted drive images and has limited fragmentation handling capabilities. Photorec Sorter can help organize recovered files by extension for easier analysis. Output: Using Photorecsorter: Move the PhotoRec Sorter executable (PhotoRec_Sorter.exe) to the directory containing the "recup_dir" folders generated by PhotoRec. Execute PhotoRec_Sorter.exe from the same directory. Monitor the console output for any messages or errors during the sorting process. Once PhotoRec Sorter has finished execution, navigate through the "recup_dir" folders to ensure all files are properly sorted. Check for any files that may not have been sorted correctly and manually move them to the appropriate folders based on their file extensions. Conclusion: By leveraging techniques such as datastream carving, file carving, and metadata parsing, forensic investigators can extract valuable evidence from storage devices like SSDs. These techniques play a crucial role in e-discovery cases, legal proceedings, and criminal investigations, providing insights that can strengthen legal arguments and uncover hidden truths. Akash Patel

1. UserAssist Key Understanding the UserAssist Key: The UserAssist key, located within the NTUSER.DAT hive of the Windows registry, contains valuable information about GUI program executions initiated by users. This key stores details such as the last run time, run count, name of the GUI application, focus time, and focus count for each program launched in Windows Explorer. Analyzing UserAssist Data: Forensic analysts can leverage the UserAssist key to uncover important details about program executions, including Last Run Time (UTC): The timestamp indicating when a program was last executed by the user. Run Count: The number of times a program has been executed on the system. Name of GUI Application: The name or identifier of the GUI application launched by the user. Focus Time and Focus Count: Metrics indicating the total time an application has been in focus and the number of times it was re-focused in Windows Explorer. Understanding GUIDs and Execution Modes: Each application launch generates unique GUIDs within the UserAssist key, distinguishing between executable file executions and shortcut file executions. For example: GUIDs for Windows XP: GUIDs such as 5e6ab780 represent Internet Toolbar, 75048700_ signifies Active Desktop. GUIDs for Windows 7 and higher: GUIDs like CEBFF6CD denote executable file execution, F4E57C4B indicates shortcut file execution. Understanding GUIDs and Execution Modes: Each application launch generates unique GUIDs within the UserAssist key, distinguishing between executable file executions (CEBFF6CD) and shortcut file executions (F4E57C4B). By analyzing these GUIDs, forensic analysts can discern how users interact with applications, whether through direct executions or shortcut activations. 2. Shimcache (Application compability cache)/ Amcache Hive Shimcache Purpose • Checks to see if application needs to be "shimmed" (properties applied) to run application on current OS or via older OS parameters • AppCompatCache will track the executable file's last modification date, file path, and if it was executed • Advanced: Applications will be shimmed again (w/ additional entry) if the file content is updated or renamed. Good for proving application was moved, renamed, and even time stomped (If current File's Mod-time * ShimCache Mod-time) Amcache Purpose: •Application Experience Service •New AppCompat structure and full of additional information To understand in deep Kindly go through my previous blog link below... Blog Headline : Forensic Collection of Execution Evidence through AppCompatCache(Shimcache)/Amcache.hiv Blog Link: https://www.cyberengage.org/post/forensic-collection-of-execution-evidence-through-appcompatcache-shimcache--amcache-hiv Blog Headline: Shimcache/Amcache Analysis: Tool-->AppCompactCacheParser.exe/AmcacheParser.exe Blog Link: https://www.cyberengage.org/post/shimcache-amcache-analysis-tool-appcompactcacheparser-exe-amcacheparser-exe Blog Headline: Amcache.hiv Analysis: Tool--> Registry explorer Blog Link: https://www.cyberengage.org/post/amcache-hiv-analysis-tool-registry-explorer 3. BAM/DAM Record information about executed programs, including the path of the executable and the date/time of the last execution. The DAM is specifically found on systems with connected standby, a feature that allows Windows to remain powered on while the screen is turned off, similar to the standby mode on smartphones. The DAM helps manage desktop application access to extend battery life while ensuring that system processes can still function effectively. On the other hand, the BAM is associated with a kernel mode driver service that was introduced in Windows 10 version 1709. While there is limited official information available about the BAM, forensic analysts have observed similarities between the information recorded in BAM and DAM keys. Within these registry keys, you can find entries corresponding to various programs. Each entry will contain details such as the full path of the executable and the timestamp of the last execution. System Hive: (BAM/DAM) SYSTEM\CurrentControlSet\Services\bam\UserSettings\{SID} SYSTEM\CurrentControlSet\Services\Dam\UserSettings\{SID} Akash Patel

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