top of page

Search Results

514 results found with an empty search

  • Log Analysis on macOS(Part 2) : A Creative Approach

    Logs are like digital breadcrumbs—traces of system activities that tell a story. But with millions of log entries, scrolling aimlessly isn't an option. The real skill lies in creativity: knowing what to look for and how to find it efficiently. Think Outside the Log File Log analysis isn't just about running commands; it's about asking the right questions. Need to know when a USB drive was plugged in? Want to track down a rogue software install? It's all there in the logs—you just need to know where to look. Key Areas of Log Analysis Volume Analysis : External drives, network shares, historical volume usage System State : Boot, reboot, shutdown, system sleep/wake, disk usage Software : Installed applications, system updates, kernel extensions AirDrop Activity : Tracking file transfers between devices ------------------------------------------------------------------------------------------------------------ Volume Tracking: Who Mounted What and When? macOS Finder: Tracking Mounted Volumes macOS stores mounted volumes in com.apple.finder.plist at: ~/Library/Preferences/com.apple.finder.plist Data captured using UAC Script: The FXDesktopVolumePositions  key logs mounted volumes and their positions on the desktop. While it doesn’t store timestamps, pairing it with system logs can help reconstruct events. P ro Tip:  If the Finder preference to show volumes on the desktop is disabled, this key won’t exist. Favorite Volumes (Mounted and Native) Finder sidebar volumes are logged in: ~/Library/Application Support/com.apple.sharedfilelist/com.apple.LSSharedFileList.FavoriteVolumes.sfl2 This file requires manual parsing or specialized scripts like macMRU.py  to decode the contents. ------------------------------------------------------------------------------------------------------------ Unix Daily Maintenance Logs: /Volumes/ To check what volumes were mounted when macOS ran its maintenance scripts , search: /var/log/ you will find the logs of the script cat /var/log/daily.out | grep "/Volumes/" or cat /var/log/daily.out > /Users/deanwinchester/Desktop/dailyout.txt Mac runs three maintenance scripts at different intervals: /etc/periodic here script are located Daily : /etc/periodic/daily Weekly : /etc/periodic/weekly Monthly : /etc/periodic/monthly These scripts generate logs that can reveal disk usage trends and mounted volumes over time. /System/Library/LaunchDaemons/ from here scripts will be run or executed com.apple.periodic-daily.plist com.apple.periodic-weekly.plist com.apple.periodic-monthly.plist ------------------------------------------------------------------------------------------------------------ Unified Logs & System Logs: Tracking Mounted Volumes if you remember in our previous article we have created an log archive. We are going to use same in this part of article. For more detailed tracking, search system logs: log show --predicate 'eventMessage contains "mounted"' --info log show --predicate 'eventMessage contains "unmounted"' --info or log show system_logs.logarchive -- info -- predicate 'eventMessage contains "/Volumes"' This can reveal UUIDs, mount points, and timestamps for external drives. or If you remember we used unified log parser to parse db/tracev3/timesync logs After running the tool we got output in sqlite, you can search from there as well example : ------------------------------------------------------------------------------------------------------------- USB Device Tracking: Who Plugged What In? To track USB mass storage devices, search for USBMSC in system logs: log show --predicate 'eventMessage contains "USBMSC"' --info or Log show system_logs.logarchive -- info -- predicate 'eventMessage contains "USBMSC"' This will reveal: Serial Number : Unique (sometimes) Vendor ID : Manufacturer of the device Product ID : Device model Version : Firmware version Heads-Up:  Built-in SD card readers generate USBMSC logs too. To avoid false positives, correlate timestamps with user activity. ------------------------------------------------------------------------------------------------------------- Network Shares: Who Accessed What? macOS unified logs track network share connections via the NetAuthSysAgent  process. Searching for terms like smb://, afp://, or loginsupport  can uncover mounted shares and user authentication details. log show --predicate 'eventMessage contains "smb://"' --info Or you can use logs which we parse using unified log parser in windows ------------------------------------------------------------------------------------------------------------- Next Logs we are going to talk about System Information and State When investigating a macOS system, understanding its boot, reboot, and shutdown patterns can provide valuable insights. Boot, Reboot, and Shutdown Logs macOS handles system startup and shutdown processes differently depending on the version. Here’s what you need to know: macOS 10.13.1 and later:  The system.log file contains timestamps for BOOT_TIME and SHUTDOWN_TIME, recorded in Unix epoch format. cat system.log | grep "_TIME" UAC Script collected artifact: Unified Logs:  These logs track which user initiated a shutdown (halt). If a system reboot occurs, it records shutdown: reboot by . macOS 10.12.0–10.12.2:  Shutdown messages are mysteriously absent from logs. How to Determine a System Shutdown or Restart macOS logs specific messages that indicate whether a system was shut down, restarted, or if an attempt was canceled . These messages are found in logs associated with SessionAgentNotificationCenter: Command: log show --predicate 'eventMessage contains "com.apple.system.loginwindow" and eventMessage contains "SessionAgentNotificationCenter"' or log show system_logs.logarchive --predicate 'eventMessage contains "com.apple.system.loginwindow" and eventM essage contains "SessionAgentNotificationCenter"' com.apple.system.loginwindow.shutdownInitiated  – User manually initiated a shutdown. com.apple.system.loginwindow.logoutcancelled  – User canceled a shutdown, restart, or logoff. com.apple.system.loginwindow.restartinitiated  – User chose to restart the system. What Do Shutdown Causes Mean? macOS logs also record the reason behind a shutdown or sleep event. You’ll typically see entries like: Previous sleep cause: 5, Previous shutdown cause: 5  → Normal sleep or shutdown. Negative numbers  → Often indicate an error. 0  → System hibernation (sleep) or power loss (shutdown). 3  → Hard shutdown (e.g., holding down the power button). Wake Reasons – What Woke the Mac? The system also records why it woke up from sleep. Here are some common wake reasons: EC.RTC (Alarm), RTC (Alarm):  Wake-on-Demand via Bonjour Services or Real-Time Clock. EC LID0, EC.LidOpen, EC.LidOpen XHC1:  Laptop lid was opened. EHC1, EHC2:  USB, Bluetooth, or wireless device activity. PWRB (User):  Power button was pressed. USB1:  Trackpad activity. EC.ACAttach/EC.ACDetach:  Power adapter was connected or disconnected. ------------------------------------------------------------------------------------------------------------- Next Tracking Disk Usage Over Time Sometimes, understanding how disk space fluctuates can be important, whether for system performance monitoring or forensic analysis . macOS keeps a history of disk usage in /var/log/daily.out, which is updated as part of Unix maintenance scripts. cat /var/log/daily.out | grep "/dev/disk1s1" This will show how much disk space was used over time for the specified disk. ------------------------------------------------------------------------------------------------------------- Next Tracking Application Bundle or Info.plist File Before i start you might ask question Dean what is Application bundle? So, Application bundles are designed to keep everything organized in one place When you right-click an application and select “Show Package Contents” , you’ll see its internal structure. Here’s what you’ll typically find: Info.plist  – The heart of the bundle, this file stores essential metadata about the application. MacOS Directory  – Contains the executable code that launches the app. Resources Directory  – Stores images, icons, and other assets used by the app. Frameworks & Plug-ins  – Additional components that the app might rely on. This structure ensures that all dependencies remain self-contained, reducing compatibility issues and making apps more portable. Breaking Down the Info.plist File The Info.plist  (Information Property List) is an XML file that holds critical details about the app, including: Bundle Name  – The official name of the application. Bundle Version  – The specific version number. Bundle Identifier  – A unique identifier, often in reverse domain notation (e.g., com.apple.Safari). Executable Filename  – The actual file that runs when the app is opened. System Compatibility  – Specifies the minimum macOS version required. Privacy Keys  – Declares what system resources the app may access, like the camera or microphone. For example, an app might specify that it belongs to the Productivity  category, supports opening specific file types, or integrates with particular web services. This is especially useful for forensic investigations or debugging unknown applications. ------------------------------------------------------------------------------------------------------------- Next Tracking macOS Install History If you need a record of what software was installed on your system and when it happened, macOS maintains an install history file: Install History:  /Library/Receipts/InstallHistory.plist This file logs details such as: Software package names Timestamps Installation method (System OS Installer, App Store download, etc.) You can use this file to verify which updates or new software installations have taken place on your Mac. ------------------------------------------------------------------------------------------------------------- Next Tracking macOS Receipt Files Every software package installed on macOS generates receipt files  stored in: /var/db/receipts/ Each installed package has two components: .plist file  – Stores metadata like package name, install timestamp, and installer process .bom file  – Bill of Materials file, listing all files installed with the package To analyze a .bom file, use the command: lsbom /var/db/receipts/.bom ------------------------------------------------------------------------------------------------------------- Next Tracking Installed Software via Logs macOS maintains an install log  that records software installations and updates . You can check it using: Install Log File: /var/log/install.log or /private/var/log/install.log To quickly find installed software, search the log with: grep "Installed" /var/log/install.log This log tracks where an app was installed from and whether administrator privileges were required. However, it does not  log software installed via simple drag-and-drop  methods (e.g., Firefox, Chrome, or any app copied directly into the Applications folder). ------------------------------------------------------------------------------------------------------------- Next Tracking Network Usage in Logs Want to check network activity? Use this log query to filter for wireless connection changes: log show --info --predicate 'senderImagePath contains[cd] "IPConfiguration" and (eventMessage contains[cd] "SSID" or eventMessage contains[cd] "Lease" or eventMessage contains[cd] "network changed")' This command pulls entries where the system connects to different Wi-Fi networks, helping track internet usage and movement. ------------------------------------------------------------------------------------------------------------- Next Tracking Wireless Activity Timeline: system.log & Unified Logs By searching for “configd” , “SSID” , or “en0” , you can create a detailed timeline of wireless activity, showing when and where a Mac connected to various networks. ------------------------------------------------------------------------------------------------------------- Next Tracking International Travel Through Country Codes Did you know your Mac logs the country code of Wi-Fi access points? Pre-macOS 10.8 : Recorded in kernel.log macOS 10.8+ : Stored in system.log macOS 10.12+ : Found in Unified Logs ------------------------------------------------------------------------------------------------------------- Next Tracking AirDrop Activity AirDrop transfers are logged in Unified Logs , which can help analysts determine when files were sent or received between Apple devices. If both devices are available for analysis, the AirDrop ID  can link them together. Otherwise, tracking becomes more challenging. AirDrop Log Entries: Sending a file:  Logs show the sender’s device and recipient Receiving a file:  Shows sender details, file type, and whether it was accepted or declined Accepted transfers:  Indicate whether the file was imported into the Photos app or another directory ------------------------------------------------------------------------------------------------------------- Next Tracking Kernel & System Extensions Apple has tightened security in recent years, limiting how third-party extensions operate. Kernel Extensions (Kexts) – The Old Way Kernel Extensions (.kext files) provide deep system access, often used for: Device Drivers  – Hardware support. Network Filters  – Firewalls, VPN software. File System Support  – Enabling third-party file systems like macFUSE. Key Commands for Kernel Extensions List loaded kernel extensions:   kmutil showloaded  (replaces the older kextstat command) View installed kexts on a non-live system: /private/var/db/loadedkextmt.plist Apple began phasing out kexts in macOS 10.13 (High Sierra) by requiring User-Approved Kernel Extension Loading , making unauthorized kexts harder to install. System Extensions – The Future Introduced in macOS 10.15 (Catalina), System Extensions  are the modern, secure replacement for kexts. Unlike kexts, they: ✅ Run in user space , not in the kernel, reducing system crashes. ✅ Require specific entitlements , meaning Apple tightly controls their use. ✅ Cover areas like DriverKit, Network Extensions, and Endpoint Security . Key Commands for System Extensions List loaded system extensions:   systemextensionsctl list ------------------------------------------------------------------------------------------------------------- Wrapping Up macOS provides structured data that can help you dig deeper. By knowing where to look, you can gain valuable insights into your system’s software history. 🚀 Stay curious, explore, and keep learning!  🚀 -------------------------------------------Dean------------------------------------------------------------

  • A Curious Case with SentinelOne: Same Rule, Different Behavior?

    #### April, 2025, if this get resolved in future will update the same#### Hey folks! First off, a big thanks to everyone who’s been following my SentinelOne series . 🙌 If you haven't already, you can check out the full series below (yep, shameless plug, but it's worth it I promise 😅). https://www.cyberengage.org/courses-1/mastering-sentinelone%3A-a-comprehensive-guide-to-deep-visibility%2C-threat-hunting%2C-and-advanced-querying%22 Now, let me share something interesting — or maybe a little odd — that I came across while working with SentinelOne recently. It all started when a dearest friend of mine, Cesar Cobena , pinged me with a small issue. Little did we know, this would turn into a whole discovery. ----------------------------------------------------------------------------------------------------------- 🧐 The Issue: File Not Blocked? Cesar told me that SentinelOne wasn’t blocking a file  — in this case, a simple Mouse Mover  executable. Now, if you’ve used SentinelOne before, you probably know this: i t doesn't allow file name–based blocking . It focuses on hash-based blocking , and in the newer versions, it even supports SHA-256 based blocking . That’s a good sign, showing how the platform is evolving. But still, that got me thinking. ----------------------------------------------------------------------------------------------------------- 🧪 Testing Time: Let’s Try RDP Tools So, I jumped into testing mode — like any good cyber nerd would.I picked two popular RDP tools: AnyDesk  and TeamViewer . Now remember, if you block their hashes, they won’t run — fair . But what if you want to block them using file names ? SentinelOne doesn’t support that directly, but here’s the workaround: You can use STAR custom rules  to create detections based on certain conditions, including file names. So that’s exactly what I did. I created a custom STAR rule to block AnyDesk.exe  and TeamViewer.exe . And guess what happened? 🤯 ----------------------------------------------------------------------------------------------------------- 💥 Different Behavior for the SAME Rule? Here’s where things got interesting: For TeamViewer : SentinelOne triggered an alert , said the session was killed, and marked it as quarantined . But when I checked — guess what — the file was still there  on the system. ❌Only the session was ended, but the file was not actually quarantined. For AnyDesk : The alert triggered the same way — session killed, but this time , the file was actually removed from the system . ✅A clean quarantine and removal. Just as expected. Wait… what? The same rule , but two different results? --------------------------------------------------------------------------------------------------------- 📩 So I Reached Out to SentinelOne Naturally, I raised this with SentinelOne support. And here’s what they told me: “This is expected behavior with STAR rules. These rules are designed more for detection and mitigation rather than real-time blocking. STAR rules typically use 'Mark as Threat' which marks the Storyline as a threat and mitigates all processes involved.” They further explained the process: A user executes a command. Event is sent to the SentinelOne cloud (SDL). STAR rule matches the event. A response command is produced. Agent performs mitigation (can take up to 1 min). They added that STAR rules are not intended to block applications in real-time , and for real prevention, you should use hash-based blocking  via user-defined blocklists . All good — makes sense to a point. But I wasn’t satisfied yet. --------------------------------------------------------------------------------------------------------- 🤔 So I Asked Again... Here’s what I asked them directly: Why does the same STAR rule quarantine and remove the file for AnyDesk, but only ends the session (without removing the file) for TeamViewer? Is there another way to block applications by file name — considering attackers often change hashes but filenames often remain similar? Their reply this time shocked me : “It depends on the source process  — the process that initiated the session.” In interactive sessions, the source process might behave differently compared to non-interactive sessions, which can impact how mitigation occurs.” So basically… even if the rule  is the same, how  the application runs (and what process starts it) can result in completely different behaviors  in SentinelOne. --------------------------------------------------------------------------------------------------------- 🧠 Final Thoughts (and a Little Rant) I get that SentinelOne is evolving — and honestly, it's still one of the best MDR solutions out there. But quarantine should mean quarantine . Period. Not “well, the process was killed but the file stayed” — that’s confusing, especially for analysts trying to understand if a threat was fully neutralized. I’m sharing this because some of you might run into the same behavior  and start wondering “is it a bug?” or “did I do something wrong?” — You didn’t. This is just how it works currently . So if you’re following my articles or learning from my experiences — make sure you don’t just stop at alerts. Always verify manually whether the file was actually removed . And of course, if you notice anything odd — reach out to SentinelOne . They’re usually very responsive and open to feedback. --------------------------------------------------------------------------------------------------------- 🔧 TL;DR (Because Who Doesn’t Love One?) SentinelOne doesn’t support file name–based blocking, only hash (now with SHA-256 too). STAR rules are for detection and response, not real-time blocking. Custom rules may behave differently based on how the app was launched (source process). Same rule ≠ Same outcome. Always check if files are actually  quarantined — don’t assume based on the alert. --------------------------------------------------------------------------------------------------------- If you’ve experienced something similar, or found a clever workaround — hit me up or drop a comment! Let’s keep learning from each other. Until next time, – Dean🔍 ----------------------------------------------Dean---------------------------------------------------

  • Making Sense of macOS Logs(Part1): A User-Friendly Guide

    If you've ever had to analyze logs from different systems, you know how frustrating it can be to correlate events across multiple time zones. Logs from different sources store timestamps in various formats, and some tools even output timestamps in local system time instead of UTC. And If i talk about MAC One tool that presents this challenge is praudit , which reads BSM audit logs and outputs timestamps in the local system time. To get accurate results, you must know the original time zone of the system before interpreting the log data. -------------------------------------------------------------------------------------------------------- A Quick Fix: Changing Time Zone in Terminal One simple trick for investigators is temporarily changing the Terminal's time zone. This can be done using: export TZ="UTC" This adjustment ensures logs are displayed in UTC for consistency. The change only lasts for the current session, so once you exit the Terminal, it reverts back to the system's original time zone. -------------------------------------------------------------------------------------------------------- Next Question is where to Find macOS Logs? macOS stores logs in several locations, categorized into system logs, user logs, and application logs . System Logs Other Logs /private/var/log /Library/Logs - Common Unix Logs - User Logs - Apple System Log (ASL) - ~/Library/Logs - Audit BSM Logs - Application Specific /var/db/diagnostics (& /uuidtext/) - /Library/Application Support/ - Unified Logs - /Library/Logs ----------------------------------------------------------------------------------------------------------------- Next question is what is the macOS Log Formats? Most macOS logs follow the Standard Unix Log Format , which looks like this: MMM DD HH:MM:SS Host Service: Message One thing to note: this format doesn’t always include the year or time zone, making it harder to pinpoint exact events. However, most logs are stored in plaintext, making them easy to read. ----------------------------------------------------------------------------------------------------------------- UAC Script collecting Logs If you have seen the screenshot log is in .gz and .bz2 format Next question will be How to Deal with Compressed Logs? Old macOS logs are compressed using bzip2 or gzip  to save space. You can decompress and merge logs using these commands: For Bzip2 Logs: bzcat system.log.{5..0}.bz2 > system_all.log For Gzip Logs: gzcat system.log.{5..0}.gz > system_all.log This creates a single log file where events are arranged from oldest to newest, making it easier to analyze. Merging Current Log Files After decompressing old logs, you might want to merge them with the latest logs: cat system.log >> system_all.log This ensures you have a complete log timeline for investigations ----------------------------------------------------------------------------------------------------------------- First Log we are going to Talk about are ASL Logs ASL is basically known as Apple System Logs. Unlike standard plaintext logs, ASL files are stored in a proprietary binary format, requiring specialized tools for interpretation. Where to Find ASL Logs Post macOS version 10.5.6 , ASL logs are stored in: /private/var/log/asl/ The logs can be accessed through Console.app  or the syslog command-line tool. Key Characteristics of ASL Logs Binary format:  Identified by the signature ASL DB in the first six bytes of the file. Log retention:   System logs are retained for seven days , while logs related to user sessions (utmp, wtmp, lastlog ) persist for one year . File Naming Convention: Format: YYYY.MM.DD.[UID].[GID].asl Special files: BB (Best Before):  Contains login records for a given month and are kept for a year . AUX (Auxiliary):  Introduced in macOS 10.8+, these directories store additional text-based data referenced by ASL logs. UAC Script Logs Extracting and Viewing ASL Logs Since ASL logs are in binary format, they require the syslog command for human-readable output. You can specify different output formats: Output Formats: bsd : Similar to system.log. std : Default format with priority levels. raw : Displays log messages in key-value pairs. xml : Outputs logs as an XML property list. Example Commands: View logs in UTC time and raw format: (To view into Terminal) syslog -T utc -F raw -d /var/log/asl Extract ASL logs and convert them into a readable format: (To view into txt file) syslog -F std -d /var/log/asl > asl_logs.txt Key Fields in ASL Logs (raw format view in terminal) Each log entry contains various attributes that can provide insights into system activity. Some of the most useful fields include: Time:  Timestamp of the record. Host:  System hostname. Sender:  Process or service that generated the log. PID:  Process ID. UID/GID:  User and group IDs. Level:  Priority level of the message. Message:  The actual log message. Session:  Associated session (managed by launchd). ASLAuxTitle:  Typically labeled "Full Report." ASLAuxURL:  URL linking to additional auxiliary logs. Working with Archived Logs ASL logs, like other system logs, undergo log rotation . Older logs are compressed using bzip2 or gzip. To decompress and merge archived logs: bzcat system.log.{7..0}.bz2 > merged_system.log cat system.log >> merged_system.log This command stitches together log files from oldest to newest, creating a unified log for analysis. ----------------------------------------------------------------------------------------------------------------- Second Log we are going to Talk about are Unified Logs A New Era of Logging With macOS 10.12 and iOS 10, Apple introduced Unified Logging , a major overhaul that replaced the traditional Apple System Logs (ASL)  and Syslog . This new system provides a consistent logging experience across macOS, iOS, watchOS, and tvOS, making it easier for developers and forensic analysts to work with log data efficiently. Unlike the older log formats, which stored logs in plaintext or simple binary files, Unified Logging uses a structured binary format  stored in: /var/db/diagnostics/  (main log storage) /var/db/uuidtext/  (referenced data) ( or you can check /private/var/db/) The log files themselves have a .tracev3 extension, which requires specialized tools to interpret. Collecting Unified Logs Apple provides the log collect command to gather system logs efficiently. When run with root privileges , this command generates a structured logarchive  bundle that includes all relevant log files. Command to Collect Logs: log collect This command outputs a system_logs.logarchive  folder containing Bundled .tracev3 files Referenced data from /var/db/uuidtext/ If you're analyzing a system image where log collect isn't possible, you can manually create a log archive: cp -R /private/var/db/uuidtext/ /private/var/db/diagnostics/ logs.logarchive /usr/libexec/PlistBuddy -c "Add :OSArchiveVersion integer 4" logs.logarchive/Info.plist Without this Info.plist file, macOS won’t recognize the manually created archive. Viewing Logs in Console.app The e asiest way to explore collected logs is via Console.app , Apple’s built-in log viewer. Simply open the system_logs.logarchive file in Console, and you’ll see logs categorized by time, process, and severity level. Note: Capture logs in real-time using the log collect command. Because of reboot some logs might be lost Parsing Logs with log show (Live System) For command-line users, the log show command allows for deeper analysis of .tracev3 files. Viewing System Logs: log show This outputs system logs in chronological order  but excludes  info and debug messages by default . To include them, use: log show --info --debug Filtering Logs with Predicates One of the most powerful features of Unified Logging is its filtering capabilities  using the --predicate  argument. You can narrow down logs based on specific conditions: Example: Find All Error Messages log show --predicate 'messageType == "Error"' Example: Find Logs from a Specific Process log show --predicate 'processImagePath CONTAINS "Safari"' Other Useful Filters: eventType:  Filters by event type (Log, Trace, Activity) eventMessage:  Filters log message text messageType:  Filters by log level (Info, Debug, Error, Fault) subsystem:  Filters by system component (e.g., “com.apple.network”) category:  Filters by log category Filter log events using logical statements (AND/OR/NOT/</>/=/CONTAINS/BEGINSWITH/TRUE/FALSE, etc.) With these filters, analysts can efficiently extract valuable insights from massive log datasets. ------------------------------------------------------------------------------------------------------------ Parsing Unified log on Window If you've collected macOS logs using a tool like UAC  and need to analyze them on a Windows system , you might wonder—how do you efficiently parse these logs? Worry not, I’ve got you covered! Introducing Unified Log Reader A fantastic tool created by Yogesh Khatri , Unified Log Reader allows you to extract and analyze macOS logs on Windows. You can find the tool here: 🔗 Unified Log Reader GitHub Repository Installation & Usage Download  the Unified Log Reader tool from the link above. Run the following command  to parse your collected logs: UnifiedLogReader.exe -f SQLITE "E:\Output for testing\uac-Deans-Mac.local-macos-20250222225422\[root]\private\var\db\uuidtext" "E:\Output for testing\uac-Deans-Mac.local-macos-20250222225422\[root]\private\var\db\diagnostics\timesync" "E:\Output for testing\uac-Deans-Mac.local-macos-20250222225422\[root]\private\var\db\diagnostics" "C:\Users\Akash's\Downloads" Output: Understanding the Command Arguments uuidtext_path  → Path to the uuidtext  folder (e.g., /var/db/uuidtext). timesync_path  → Path to the timesync  folder (e.g., /var/db/diagnostics/timesync). tracev3_path  → Path to a tracev3 file  or a folder containing tracev3 logs (e.g., /var/db/diagnostics). output_path  → The folder where the parsed logs  will be saved. Notes: If you have a .logarchive file, set the uuidtext_path to the .logarchive folder. The timesync  folder is located within it. The tool supports different output formats: SQLITE (Recommended for structured analysis) TSV_ALL (Tab-separated format) LOG_DEFAULT (Standard log format) This method enables you to analyze macOS logs efficiently on Windows , making forensic investigations much easier. 🚀 ----------------------------------------------------------------------------------------------------------------- Third Log we are going to Talk about are Audit Logs The macOS Audit Logs, stored in ( /private/var/audit/ or /var/audit/ check both) , are a goldmine of information that can help security professionals track events like logins, privilege escalations, and system modifications. However, these logs aren’t your typical plain-text files; they use a structured binary format and require special tools to read them What are BSM Audit Logs? macOS uses the Basic Security Module (BSM) Audit Logs , a system originally developed by Sun Microsystems  and later maintained by TrustedBSD . These logs help ensure security compliance by recording detailed system activities. Unlike traditional log files in /var/log/, these audit logs are found in /var/audit/ and store data in a binary format , making them harder to tamper with. Filename Structure Each log file follows a specific naming convention  based on timestamps: Audit Trail Files : YYYYMMDDHHMMSS.YYYYMMDDHHMMSS Current Log File : Symbolic link named current pointing to the active log. not_terminated : Files that were not terminated properly due to a system error, or the file was otherwise inaccessible.. Crash Recovery Logs : Files ending in .crash_recovery (generated after a system or audit crash). Collected using UAC Script Configuration Files: How Auditing Works ( /etc/security/) The auditing behavior in macOS is controlled by configuration files stored in /etc/security/. These files determine what gets logged and how long the logs are retained. Key Configuration Files audit_class  – Defines event classifications (e.g., login/logout, system changes) . audit_control  – Specifies audit settings: dir: Location of audit logs (/var/audit/). flags: Specifies which events are logged. minfree: Minimum disk space required for audit logs. policy: Defines global audit policies. filesz: Maximum file size for logs. expire-after: Log retention period based on time or size. audit_user  – Customizes auditing per user . audit_event  – Lists auditable events with unique event IDs. eventnum: Unique number for the event eventname: Event Name description: Event Description eventclass: Event class (see audit_class) Interpreting Audit Logs Audit logs aren’t human-readable by default, so you need special tools to analyze them. + 1. Viewing Audit Logs with praudit The praudit command prints audit logs in readable formats. Example: praudit -xn /var/audit/* or sudo praudit -xn /var/audit/20250226082421.not_terminated > /Users/deanwinchester/Desktop/audit.log -x prints logs in XML format. -n prevents conversion of user and group IDs to names. 2. Filtering Logs with auditreduce Need to extract specific log events? Use auditreduce: auditreduce -m AUE_lw_login /var/audit/* | praudit or sudo auditreduce -m AUE_lw_login /var/audit/20250226082421.not_terminated | praudit Output Lets understand the output: First Part: header, 128, 11, loginwindow login, 0, Wed Feb 26 00:25:24 2025, + 721 msec header  → The start of an audit event. 128  → Event record size. 11  → Event version. loginwindow login  → The process responsible for the login (GUI-based login). 0  → Indicates no special flags. Wed Feb 26 00:25:24 2025, + 721 msec  → Timestamp of the login event. Second Part subject_ex, deanwinchester, root, wheel, deanwinchester, staff, 152, 100006, 50331650, 0.0.0.0 subject_ex  → The user and group context of the action. deanwinchester  → The user who logged in. root  → The effective user ID (root privileges were used at some point). wheel  → The user group (admin privileges). deanwinchester  → The real user performing the action. staff  → The user’s group. 152  → The process ID (PID) of the login session. 100006  → Audit session ID. 50331650  → Terminal session ID. 0.0.0.0  → The source IP address (in this case, local login). Third Part return, success, 0 return  → Status of the event. success  → Indicates the login was successful. 0  → No errors. Fourth Part identity, 1, com.apple.loginwindow, complete, , complete, 0x0e6dce00ff9c249a49f9dde396 identity  → The authentication method used. 1  → Likely represents a local user login. com.apple.loginwindow  → The process responsible for the login. complete  → Authentication was fully completed. 0x0e6dce00ff9c249a49f9dde396  → A unique identifier for the session. Summary This log entry documents a successful login  to the macOS system via the login window (GUI-based login) . The user deanwinchester logged in locally, and the authentication process completed successfully. 3. Searching for Suspicious Activity To find all authentication failures: auditreduce -m AUE_auth_fail | praudit To track when a user switches to root: auditreduce -m AUE_su | praudit Why Are macOS Audit Logs Important? Audit logs play a crucial role  in security monitoring, forensics, and compliance. They help: ✅ Detect unauthorized access attempts. ✅ Investigate suspicious activities. ✅ Ensure compliance with security regulations. ✅ Provide forensic evidence in incident response cases. ----------------------------------------------------------------------------------------------------------------- Conclusion macOS logs may seem complex at first, but they offer powerful insights  into activities. With tools security analysts can uncover hidden threats  and ensure system integrity. If you're serious about macOS security, mastering these logs is a must ! 🚀 Got any questions or want to see more examples? Let’s discuss! ---------------------------------------------Dean-------------------------------------------------------

  • macOS File System Events: The Power of Spotlight

    Ever wondered how macOS allows users to instantly find files, emails, photos, and even downloaded apps? The magic behind this lies in Spotlight , a powerful indexing tool that organizes data and makes it searchable. ------------------------------------------------------------------------------------------------------------- Understanding Spotlight and How It Works Spotlight creates a searchable index of everything on the system. It catalogs files, applications, and even metadata like timestamps, authorship details, and download history. What Gets Indexed? Practically Everything! Spotlight doesn’t just track filenames—it goes much deeper. Some examples of what it captures include: File system metadata : Filenames, sizes, user IDs (UID/GID), timestamps Timestamps : Last used, download date, and date added Photos data : Camera make/model, resolution, aperture, ISO settings Authorship details : Originating user and the application used to create the file App Store metadata : If an app was downloaded from the App Store, receipt data is indexed Communication info : Email senders, AirDrop sender details, and shared file information By default, Spotlight indexes system and external drives but excludes certain locations  like DMG files, hidden files, system directories, CDs/DVDs, and drives explicitly marked with .metadata_never_index. Spotlight: User Shortcuts For particular user you can find Spotlight in location: (For MAC (10.15+)) Location: /Users/deanwinchester/Library/Application Support/com.apple.spotlight Command: plutil -p com. apple. spotlight.Shortcuts.v3 Spotlight’s Hidden Treasure: The .Spotlight-V100 Directory Forensic analysts looking for juicy metadata should head to .Spotlight-V100 , found at the root of indexed volumes. This directory contains: Command On live system: Directory: ./System/Volumes/Data Command: ls -lar VolumeConfiguration.plist  – Lists volumes excluded from indexing store.db  – The main Spotlight indexing database /Cache Directory  – Stores text-based versions of documents, emails, and chats Each file in the cache directory is named after its inode number, making it possible to track the original file using: sudo find -inum However, be aware that once a file is deleted or moved to the trash, these cached text files are gone. Command-Line Tools for Spotlight Metadata Analysis 1. mdimport – Checking Available Metadata Attributes This command shows the types of metadata attributes indexed by Spotlight: mdimport -A # Lists all available metadata attributes mdimport -X # Lists metadata attributes for specific file types (e.g., photos) 2. mdfind – Searching Files Using Metadata Spotlight allows powerful metadata-based searching. For instance, to find files that contain geolocation data: mdfind kMDItemLongitude To search within a specific directory (though -onlyin is broken in macOS 11+): mdfind -onlyin /Users/Documents kMDItemAuthors 3. mdls – Listing Metadata of a Specific File For a deep dive into an individual file’s metadata, use: mdls /path/to/file This will display: File timestamps Download history File ownership Content type and properties Spotlight and File Sharing Metadata Modern macOS versions store metadata related to file sharing, which can be invaluable for digital forensics. Two key attributes to look for: kMDItemUserSharedSentDate  – Tracks files sent via Apple Mail, iMessage, or AirDrop kMDItemUserSharedReceivedDate  – Tracks received files For example, to find files shared via AirDrop: mdfind kMDItemUserSharedSentDate This can reveal details like the sender’s iCloud username, device name, and app used (e.g., Photos or Messages). Parsing Spotlight Databases Offline If you need to extract metadata without live system access, some tools can parse the store.db file offline: 1. mac_apt  (Open-source forensic tool) GitHub: https://github.com/ydkhatri/mac_apt Written in Python, works across platforms 2. Cellebrite Inspector A commercial tool for forensic analysis Supports offline Spotlight database parsing ------------------------------------------------------------------------------------------------------------- Final Thoughts Spotlight is more than just a search tool—it’s a treasure trove of metadata for investigators. By leveraging Spotlight databases and command-line tools, forensic analysts can uncover a wealth of hidden information about file activity, ownership, and sharing history . Whether you're investigating a macOS system live or parsing data offline, these techniques can help piece together the bigger picture of digital evidence. 🔍 Pro Tip:  Always verify metadata timestamps against file system logs for accuracy, as Spotlight’s timestamps may differ from file system-level changes. Want to learn more about macOS forensics? Stay tuned for our next deep dive! 🚀 ----------------------------------------------------Dean-----------------------------------------------

  • Investigating macOS File System Events: The Hidden Forensic Trail

    Ever wondered how macOS keeps track of file system changes? Deep within the system lies a powerful yet often overlooked artifact—the .fseventsd directory. This little-known database logs file system modifications, making it invaluable for forensic investigations. Let’s dive into how it works and how you can leverage it for file activity tracking. ------------------------------------------------------------------------------------------------------------- What is the .fseventsd Directory? Each time you connect a volume (like a USB drive) to a Mac, the system creates a .fseventsd directory at the root level. This directory functions as the File System Events Store Database , recording changes to files and directories on that volume. macOS services like Spotlight  and Time Machine  rely on this data to detect new or modified files efficiently. The .fseventsd directory contains: Gzipped log files : These are sequentially named with no extensions , recording system events. The fseventsd-uuid file : A unique identifier for the database, which remains persistent on hard drives but changes frequently on external USB devices. ------------------------------------------------------------------------------------------------------------- I know you will ask question Dean, how are u able to open the MAC .fseventsd directory in windows Acquiring a full forensic image is ideal in investigations, but it's not always practical. In one case, I was assisting a client located in another part of the country, making it impossible to collect a full disk image remotely. Additionally , when individuals with limited forensic expertise are tasked with image collection, errors can occur, leading to incomplete or compromised evidence. To address this challenge, I leveraged two powerful forensic artifact collection scripts: UAC ( https://github.com/tclahr/uac ) CYLR ( https://github.com/orlikoski/CyLR ) These scripts automate the collection of critical forensic artifacts, ensuring consistency and reducing the risk of errors. For instance, in this specific case, I used UAC  to extract key forensic data from a macOS system. The script provided sufficient output for a thorough analysis without requiring full disk imaging. ------------------------------------------------------------------------------------------------------------- Why is this Important for Investigators? Forensic analysts can extract and analyze .fseventsd data to reconstruct file system activity, including: ✅ Identifying file creations, modifications, and deletions ✅ Tracing USB usage and external drive activities ✅ Recovering deleted files through metadata remnants However, there are some caveats: If the system crashes or is powered off abruptly , the .fseventsd data may be lost. The database format has evolved over time, and Apple doesn’t publicly document all changes. Non-HFS+ volumes may contain the directory but lack database logs. ------------------------------------------------------------------------------------------------------------- Extracting and Analyzing FSEvent Data Since .fseventsd files are gzipped, root access  is required to extract and view them. You can start by listing the attributes: (On Live System) ls -la .fseventsd/ To unzip and inspect them: sudo gunzip -c /.fseventsd/fseventsd-uuid While the logs aren’t easily readable, you can use strings to extract human-readable filenames and paths: sudo strings /.fseventsd/fseventsd-uuid ------------------------------------------------------------------------------------------------------------- Automating the Analysis with Python Instead of manually parsing logs, forensic analysts often use the FSEventsParser  too l. This Python script(For MAC or python) as well .exe( For Windows) Avaliable: Extracts and decodes .fseventsd logs Converts data into a SQLite database  and CSV file  for structured analysis First we talk about Python script: To use it: git clone https://github.com/dlcowen/FSEventsParser cd FSEventsParser python3 fsevents_parser.py -d /path/to/fseventsd A live system. python3 FSEParser_V4.1.py -s /.fseventsd -t folder -o /some_folder -c test_case -q report_queries.json If you are a window person like me lets talk about .exe To use it (On Collected artifact using UAC) C:\Users\Akash's\Downloads\FSEParser_V4.0_Windows_x64> FSEParser_V4.exe -s .fseventsd -t folder -o "C:\Users\Akash's\Downloads" An image file. FSEParser_V4.exe -s E:\001-My_Source_Image.E01 -t image -o E:\My_Out_Folder -c Test_Case An attached external device or mounted volume/image. FSEParser_V4.exe -s G:\.fseventsd -t folder -o E:\My_Out_Folder -q report_queries.json Output: Sqlite:- you can open with SqliteDB Tsv File you can open with Eric Zimmerman tool Timeline explorer ------------------------------------------------------------------------------------------------------------- Using Inspector for Advanced Processing Forensic tools like Cellebrite Inspector  come with built-in FSEvents parsers. When analyzing a system image, navigate to: ➡ System | System Logs  in the left sidebar ➡ Use the filter icon  to refine event searches ------------------------------------------------------------------------------------------------------------- Real-World Example: Tracking File System Events Imagine investigating a USB thumb drive  where a user created several directories and moved files. The .fseventsd logs would reveal: Mount event : The moment the drive was connected. Folder creations : Including renaming from default names like untitled folder. File additions : Such as installer DMGs and images being copied. Document edits : Tracking temporary .DocumentRevisions files before saving. Deletion tracking : Differentiating between files moved to .Trashes (recoverable) and those permanently deleted. Note the .DS_Store is shown. This means the user added these files using the Finder GUI window. ------------------------------------------------------------------------------------------------------------- Time Stamps in FSEvents Data One major limitation: FSEvents logs don’t store timestamps per event . However, we can estimate timestamps using: The created/modified timestamps  of the .fseventsd gzip files. Neighboring ASL log timestamps . Application-specific logs (e.g., chat message archives). ------------------------------------------------------------------------------------------------------------- Conclusion: A Powerful Yet Overlooked Artifact The .fseventsd directory provides a wealth of forensic insights  into file system activities on macOS. While not a perfect timeline solution, it serves as a powerful artifact for tracking file movements, external drive activity, and even partial recovery of deleted files. Whether using a Python script or forensic tools like Inspector, leveraging this data can be crucial in digital investigations. 🔎 Want to try it out?  Check out the FSEventsParser tool on GitHub: https://github.com/dlcowen/FSEventsParser . ----------------------------------------------------------Dean-----------------------------------------

  • How Windows Knows Your Files Came from the Internet: Alternate Data Streams (Zone.Identifier)

    Updated in 17 Feb,2025.. Ever downloaded a Word document or PowerPoint presentation and noticed it says "Trust this file to edit"? That happens because Windows tags downloaded files with something called a Zone.Identifier. This tag helps the system figure out if a file came from the Internet, and in some cases, even where it came from. Pretty cool, right? What Is Zone.Identifier and How Does It Work? Windows has been using the Zone.Identifier tag since Windows XP SP2. Whenever you download a file from the Internet to an NTFS drive, an alternate data stream (ADS) gets added to it. This extra data doesn’t change the file itself but contains useful information about its origin. Most web browsers (like Chrome, Edge, and Firefox) and apps like email clients automatically tag files this way. This process is known as "Mark of the Web" (MotW) . It uses the Windows API function IAttachmentExecute to make sure files are handled safely. However, there are some exceptions—Internet Explorer, for example, only tags certain file types, and PowerShell or FTP downloads often don’t get tagged at all. What’s Inside a Zone.Identifier? If you inspect a Zone.Identifier ADS using a tool like FTK Imager, you’ll see details like: ZoneID  – A number indicating the security zone the file came from. Here are the possible values: 0  – My Computer (local files) 1  – Intranet (internal network) 2  – Trusted sites 3  – Internet (most web downloads) 4  – Untrusted (flagged as risky by Microsoft SmartScreen) ReferrerURL  – The website the file was downloaded from (if available) HostURL  – The direct download link (if available) Not all browsers store ReferrerURL or HostURL, especially in private browsing modes. ------------------------------------------------------------------------------------------------ Example : Analyzing Zone.Identifier ADS: By analyzing the presence of Zone.Identifier ADS, f orensic analysts can identify potentially malicious files that were downloaded from the interne t. **This analysis is particularly useful when examining critical system directories like C:\Windows\System32, where the presence of ZoneID=3 can raise red flags. ** Applications in Forensic Investigations: ADS analysis, especially focusing on Zone.Identifier streams, can provide valuable insights into the origins of files, aiding forensic investigations in various scenarios, including malware analysis, digital forensics, and e-discovery. ----------------------------------------------------------------------------------------------------- ********************** Update Made on January 2025 I want to introduce you to one of the best tools I always use, which is also a part of the KAPE toolkit. The tool is called MFTECmd.exe . This tool parses key artifacts such as $MFT, $J, $Boot, $SDS, and $I30  and provides the output in a CSV format. Do check out the article Link below: https://www.cyberengage.org/post/mftecmd-mftexplorer-a-forensic-analyst-s-guide Now, you might be wondering why I’m telling you about this tool. Let me explain. Here’s an example: Suppose you’ve parsed an $MFT  file using MFTECmd.exe , and you have a file on the device . Now, the client wants to know how this file ended up on the system . Did the user download it? If so, from which link? If y ou’ve used MFTECmd.exe , you don’t need to worry . Simply open the output in Timeline Explorer , navigate to the Zone ID Contents  column , and check the information. As shown in the screenshot below, Zone ID 3  indicates the file was downloaded from the internet. Moreover, the URL is also mentioned in the output. See how easy and efficient it is to gather this information! ********************** ------------------------------------------------------------------------------------------------------------- How Attackers Exploit Alternate Data Streams Hackers and red-team testers love alternate data streams because they allow them to hide files in plain sight. For example, instead of storing malware as a regular .exe file, they can embed it inside an ADS attached to a harmless-looking text file. A common attack trick is running a malicious DLL stored in an ADS using rundll32.exe. Standard file listing tools won’t even see the hidden ADS, making it much harder for security tools to detect the malware. How You Can Spot and Investigate ADS Thankfully, there are ways to uncover these hidden streams: Use CMD : Run dir /r to list all data streams attached to files. Use PowerShell : Run Get-Item * -Stream * to find hidden ADS in a folder. Use forensic tools : Software like istat and icat can dig even deeper into ADS details. One place you’ll always find a ton of alternate data streams is the Downloads folder  since every file you grab from the Internet gets tagged with a Zone.Identifier. ------------------------------------------------------------------------------------------------------------- Why This Matters A huge number of security breaches start with a simple file download. Understanding how Windows tracks downloaded files can help spot suspicious activity early. If you see a weird-looking program in C:\Windows\System32 with a Zone.Identifier tag, you know something’s off. By knowing how to check for alternate data streams, you can catch hidden threats and stay one step ahead of attackers. ----------------------------------------------Dean---------------------------------------------------

  • Exploring macOS Extended Attributes: The Hidden Metadata You Didn’t Know Existed

    If you've ever wondered how macOS knows where a downloaded file came from or why certain files prompt security warnings, the answer lies in Extended Attributes (xattrs) . These hidden pieces of metadata provide valuable information about files, including download history, quarantine status, and even timestamps. ------------------------------------------------------------------------------------------------------------ File Quarantine: macOS’s Built-in Security Check One of macOS’s security features is file quarantine , which helps prevent malicious files from running unchecked. Whenever you download a file from the internet using Safari, Chrome, or other applications, macOS records details like: Download source  (e.g., the website URL) Timestamp of download The application used to download the file For instance, if you download googlechrome.dmg  from Google, macOS stores this metadata in the file’s extended attributes. The next time you open it, the system will verify whether it's safe to run. ------------------------------------------------------------------------------------------------------------ Where Are These Files Stored? By default, most downloads are saved in the ~/Downloads  directory . If you haven’t cleaned it out in a while, you likely have months (or even years!) of accumulated downloads, each packed with hidden metadata. To check if a file has extended attributes, open Terminal  and run: ls -la If you add an @ at the end of the permissions, the file has extended attributes . To view them: ls -l@ Decoding Extended Attributes macOS assigns various extended attributes (xattrs)  to files. Some of the most common include: com.apple.quarantine  – Stores security-related information, including the download timestamp, application used, and quarantine event ID. com.apple.metadata:kMDItemWhereFroms  – Contains the URL  where the file was downloaded from. xattr -p com.apple.metadata:kMDItemWhereFroms uac-3.0.0.tar.gz Once you run the above command output will be in hex format. Use cyberchef to decode it to get the URL Output example: Use Cyber chef to decode: com.apple.metadata:kMDItemDownloadedDate  – Stores the download timestamp in a binary format. To extract these attributes, use the xattr  command: xattr -p com.apple.metadata:kMDItemWhereFroms This will reveal the exact source from where the file originated! ------------------------------------------------------------------------------------------------------------ I know I know you will say dean, its very difficult to copy hex from every file and put into cyber-chef is there is better way, I will say yes Command : xattr -xl com.apple.metadata:kMDItemWhereFroms ------------------------------------------------------------------------------------------------------------- Different Browsers, Different Metadata Not all browsers store extended attributes in the same way: Safari : Stores all metadata, including download date and source. Chrome : Does not save the kMDItemDownloadedDate attribute. Firefox : Only records quarantine metadata (com.apple.quarantine). ------------------------------------------------------------------------------------------------------------- Beyond Browsers: AirDrop, Mail, and DMG Files Extended attributes aren’t just limited to web downloads . Other macOS applications use them as well: AirDrop : Stores sender details and metadata about transferred files. Mail Attachments : On some newer systems, when an email attachment has been downloaded, a few extended attributes get attached to that file. com_apple_mail_dateReceived : timestamp when the email message was received com_apple_mail_dateSent: timestamp when the email message was sent com_apple_mail_isRemoteAttachment : binary value if the attachment is local (0) or remote (1) DMG Files : macOS adds attributes like com.apple.diskimages.fsck   to track whether a disk image has been opened. com.apple.diskimages.recentcksum : Checksum information, including a Unix epoch timestamp of when the file was downloaded ------------------------------------------------------------------------------------------------------------- Investigating Property Lists from Extended Attributes(You can take this another method to parse) When analyzing macOS files, extended attributes (xattrs) often hold valuable metadata. Some of these attributes contain binary property lists (PLISTs) , which store structured information about the file. Extracting and decoding these PLISTs can reveal useful insights, such as the source of a downloaded file  or other metadata added by the system. Extracting PLIST Data from Extended Attributes To extract an extended attribute’s content, we use the xattr command. However, simply running xattr -p  prints the data in hex format , which isn’t very useful. For example, if we check the com.apple.metadata:kMDItemWhereFroms, we get a hex dump: xattr -p com.apple.metadata:kMDItemWhereFroms Converting Hex to Binary PLIST We can use xxd with the -r (reverse) and -p (plain) options to revert the hex dump back into binary format and save it as a file: xattr -p com.apple.metadata:kMDItemWhereFroms | xxd -r -p > wherefroms.plist Now, wherefroms.plist contains the original property list, but it’s still in binary format. To read it in human-friendly form , we need to convert it into a readable structure. Reading a Binary PLIST in Plaintext To print a binary PLIST directly to the terminal in a readable format, use: xattr -p com.apple.metadata:kMDItemWhereFroms | xxd -r -p | plutil -p - This command chain: Extracts the metadata (xattr -p). Converts it from hex to binary (xxd -r -p). Parses the binary PLIST into human-readable text (plutil -p -). ------------------------------------------------------------------------------------------------------------- Final Thoughts Extended attributes might be hidden from plain sight, but they play a crucial role in macOS’s security and file management system. Whether you’re a security researcher, a forensic investigator, or just a curious Mac user, knowing how to inspect and interpret these attributes can be incredibly useful. So, the next time you download a file, remember—macOS is keeping track, and now, so can you! 🚀 ---------------------------------------------------Dean---------------------------------------

  • Understanding Partitioning Schemes, FileVault 2 and macOS Encryption: A User-Friendly Guide

    When it comes to Mac systems, partitioning schemes play a crucial role in organizing data, managing storage, and ensuring smooth system operations. Whether you're installing macOS, working with external drives, or handling disk images, understanding these schemes can help you navigate storage management more efficiently. The Three Main Partitioning Schemes Mac systems primarily use three types of partition schemes: GUID Partition Scheme (GPT)  – The default for modern macOS installations . Apple Partition Scheme (APM)  – Used mainly on older PowerPC Macs . Master Boot Record (MBR)  – Mostly found on external drives and Windows-compatible disks. GUID Partition Scheme (GPT) – The Modern Standard Intel-based Macs (since 2006) and ARM-based M1/M2 Macs The GUID Partition Table (GPT) is the standard. It allows: Larger disk sizes  compared to older schemes. Up to 128 partitions  (as opposed to MBR’s limit of four primary partitions). Unique identification (GUIDs)  for disks and partitions, making them easier to manage. Backup of partition tables , which enhances reliability in case of corruption. With Apple’s newer macOS versions, GPT remains the backbone of partitioning, even as Apple transitions from EFI (Extensible Firmware Interface) to the “Apple APFS iSC” system for ARM-based Macs. Apple Partition Map (APM) – The Legacy Scheme Before Intel Macs came around, PowerPC-based Mac systems relied on the Apple Partition Map (APM ) . It worked fine for its time, but it had limitations , such as smaller disk size support . Since modern macOS versions no longer support APM for bootable drives, it’s mostly a relic of the past. Master Boot Record (MBR) – The Windows-Friendly Option MBR is a partitioning scheme commonly associated with Windows and external drives. While macOS can read and write to MBR-formatted disks, it isn’t used for booting macOS . It has significant limitations: Maximum of four primary partitions . Doesn’t support large storage devices as effectively as GPT. How macOS Structures Storage with APFS Apple’s APFS (Apple File System)  introduced a new way to manage disk partitions. While it still uses GPT, the way macOS organizes volumes has changed significantly. Here’s a typical structure: /dev/disk0  – The physical drive. /dev/disk1  – The APFS container that holds multiple volumes: /dev/disk1s1  – OS Volume (user data and system files). /dev/disk1s2  – Preboot Volume (boot-related data). /dev/disk1s3  – Recovery Volume (for troubleshooting and reinstalling macOS). /dev/disk1s4  – VM Volume (swap space and hibernation data). macOS Catalina (10.15) and Beyond Starting with macOS Catalina , Apple split the system into two separate partitions: System Partition (Read-Only, Mounted at ‘/’)  – Stores macOS core files. Data Partition (Mounted at /System/Volumes/Data/ )  – Stores user files and applications. This change mirrors how iOS devices handle system and user data separately, improving security and stability. macOS Big Sur (11.0) and Later – APFS Snapshots Apple took it further by introducing APFS snapshots  in macOS Big Sur . Instead of directly modifying the system partition, updates are now applied to a snapshot, ensuring safer and more reliable system updates. The key difference: The actual system partition  is now a sealed APFS snapshot  mounted at ‘/’. Understanding Disk Images (.DMG Files) Mac users frequently encounter DMG (Disk Image) files , used for installing software and storing disk copies. These images can use various partitioning schemes, including: GUID Partition Scheme  (common for system images and large software installations). Apple Partition Scheme  (for compatibility with older Macs). MBR  (for cross-platform use). No partition at all  (for simple data storage). Disk images can also include encryption and compression, making them flexible for security and storage management. Sparse Images and Sparse Bundles Mac’s Legacy FileVault  encryption uses two types of disk images: Sparse Disk Image (.sparseimage)  – A single growing file that expands as needed. Sparse Bundle (.sparsebundle)  – A collection of smaller files, more efficient for backups. These can be created and managed using Disk Utility  or the hdiutil  command. Useful macOS Disk Commands Mac includes powerful terminal commands for managing partitions and disk images: diskutil list  – Lists all disks and partitions. diskutil info /dev/disk(X)  – Provides detailed information about a disk. hdiutil create -help  – Displays available options for creating disk images. These commands help with troubleshooting, formatting, and analyzing disk structures efficiently. When it comes to securing your Mac, FileVault 2 is Apple's built-in full-disk encryption solution, introduced with macOS X Lion. What is FileVault 2? FileVault 2 encrypts your entire disk (except for the EFI and Recovery partitions), making sure that even if someone gets hold of your Mac, they can't access your files without your password. During setup, macOS presents a recovery key, which you can store with Apple or keep for yourself. This key is crucial—it’s the only way to regain access if you forget your password. Enterprise-Level FileVault 2 Management If you're in a business or IT environment, you might need extra tools to manage FileVault 2 across multiple devices. Here are some popular ones: Cauliflowervest  ( GitHub ) Crypt  ( GitHub ) JAMF Casper Suite  ( Website ) Legacy FileVault (The Old Version) Before FileVault 2, there was the original FileVault, now called Legacy FileVault , introduced in macOS 10.3. Unlike FileVault 2, it only encrypted your home directory, leaving everything else exposed. It stored the encrypted data in a sparse disk image, which wasn’t as secure or efficient as modern full-disk encryption. Encryption on T2 and M1 Macs: A Built-in Shield If your Mac reports “Encrypted at Rest,”  it means your T2 or M1 Mac is already hardware-encrypted, even if FileVault isn’t enabled. This provides an extra layer of protection, ensuring your data remains safe. CoreStorage: Apple’s Virtual Volume Management CoreStorage is Apple's way of managing virtual disk volumes and plays a key role in FileVault 2 encryption. Here’s a quick breakdown: Logical Volume Group (LVG):  The top-level structure, linked to a physical disk. Physical Volume (PV):  The actual disk or disk image (can span multiple disks, like in Fusion Drives). Logical Volume Family (LVF):  Contains one or more Logical Volumes. Logical Volume (LV):  The place where your file system lives. In macOS 10.10 and later, CoreStorage is enabled by default on new installs, but it doesn't necessarily mean encryption is turned on. Checking Your Disk Encryption Status To see whether your Mac is encrypted, use the diskutil  command: diskutil cs list This command lists all CoreStorage Logical Volume Groups and their encryption status. If the output shows AES-XTS encryption , that means FileVault 2 is protecting your data. Exploring Disk Partitions with Disk Utility Want to check your partitions? Run: diskutil list This command shows all your drives, their partitions, and their unique disk identifiers (formatted as disk#s#). You can also use Disk Utility.app  (found in /Applications/Utilities/) to view and manage partitions visually. APFS and FileVault 2: A New Era With the introduction of APFS (Apple File System), storage is now more flexible, allowing multiple volumes within a single container. Here’s how it works: APFS Container:  The main storage unit. Container Disks:  The logical disks within the APFS container. Physical Store Disks:  The actual hardware (SSDs, etc.). Each APFS volume has a role (e.g., Preboot, Recovery, VM, or the main OS volume ). FileVault 2 encrypts only the OS/User volume while leaving Preboot, Recovery, and VM unencrypted. The Sealed System Volume (SSV): Next-Level Security Starting with macOS 11, Apple introduced Signed System Volume (SSV) , adding cryptographic protections to prevent unauthorized system modifications. If you see the term “broken”  in diskutil output, don’t worry—it’s normal! It just means that macOS is using a sealed snapshot for security. Fusion Drives and Encryption Some Mac models (like late Mac Minis and iMacs) come with a Fusion Drive , which combines an SSD and HDD for better performance. Even in these setups, CoreStorage helps manage storage allocation, ensuring frequently used files remain on the SSD for faster access. DIY Fusion Drive Example Here’s an example where two USB thumb drives were combined to create a Fusion Drive: /dev/disk4: ~32GB /dev/disk6: ~8GB /dev/disk7 (MacHD_FUSION): The combined single partition Even though this is an unencrypted CoreStorage setup, FileVault 2 can still be enabled for added security. ----------------------------------------------------------------------------------------------------- Final Thoughts Mac’s partitioning schemes have evolved significantly, from APM  to GPT , and now to APFS-based containers . Understanding these changes helps users better manage their storage, troubleshoot issues, and optimize performance. as well as With built-in encryption on newer Macs and the flexibility of APFS and CoreStorage, Apple continues to enhance security while keeping things user-friendly. Have you enabled FileVault 2 on your Mac? If not, now’s a great time to take that extra step in securing your data! ------------------------------------------Dean----------------------------------------------------

  • APFS Disk Acquisition: From Live Data Capture to Seamless Image Mounting

    Updated on 20 Feb,2025 Understanding .plist Files (Property List Files) .plist files in macOS are like the registry  in Windows. They store important configuration settings for apps and the system. These files come in two flavors: XML Format This is the older, more human-readable format . If you open an XML .plist, you’ll see it starts with # Shows Access, Modify, and Change timestamps in seconds For nanosecond accuracy, use: stat -f %Fa # Access time stat -f %Fm # Modification time stat -f %Fc # Change time GetFileInfo : This command gives you additional details about the file, including creation and modification times. GetFileInfo ---------------------------------------------------------------------------------------------- Hard Drive Acquisition: The Hardware Hurdles Macs come in different flavors when it comes to storage. If you can remove the hard drive, you might be able to use traditional forensic acquisition methods. However, some Macs, especially MacBook Airs, use non-standard SSDs that are soldered directly onto the board. This means you can’t just pull out the drive and image it easily. For those lucky enough to be working with a removable drive, websites like iFixit  provide great guides on how to take Macs apart. Just be warned—some models are notoriously difficult to dismantle! If the SSD is non-removable, your best bet is a live acquisition method, such as Target Disk Mode or logical acquisition while the system is running. -------------------------------------------------------------------------------------------------------- Encryption Challenges: FileVault Can Slow You Down macOS uses two types of encryption: Legacy FileVault   – Encrypts only the user’s home directory. FileVault 2  – Provides full-disk encryption. If you’re dealing with an encrypted disk, you can still image it, but you’ll need the user’s password to decrypt the data. If the system is already up and running, your best bet is to acquire data in an unencrypted state while you have access. -------------------------------------------------------------------------------------------------------- Target Disk Mode (TDM): Your Best Friend If the Mac is functional, Target Disk Mode (TDM)  can be a lifesaver. This turns the Mac into an external drive, allowing you to connect it to another system via FireWire or Thunderbolt. However, note that: Some MacBook Airs don’t have FireWire or Thunderbolt ports, making TDM impossible. If the system uses FileVault 2 , you’ll need to unlock the encrypted volume first. If the Mac has a Boot Camp partition  (a Windows partition), you’ll see two separate volumes. Newer Macs with Apple Silicon (M1/M2)  require additional security steps. To enable Target Disk Mode, restart the Mac while holding “T”  until the appropriate symbol appears on the screen. -------------------------------------------------------------------------------------------------------- Dealing with Open Firmware and EFI Passwords Older Macs may have an Open Firmware password , and newer systems use an EFI password  for added security. If you’re locked out, you can try the following: Change the RAM amount and reboot. Reset the PRAM by holding Command + Option + P + R  at startup. If it’s an EFI password, you’ll need to send a request to Apple with a key hash (good luck with that). -------------------------------------------------------------------------------------------------------- System Integrity Protection (SIP): Another Hurdle System Integrity Protection (SIP) is macOS’s security feature that prevents unauthorized modifications to system files, even with root access. If SIP is enabled, you may run into acquisition errors To disable SIP: Boot into Recovery Mode  (Restart + hold CMD + R ). Open Terminal and run: csrutil disable Reboot the system. However, if the user has encryption enabled and you don’t have the password, disabling SIP won’t help much. -------------------------------------------------------------------------------------------------------- Important concept to understand while acquisition for MACOS Disk Arbitration: Controlling Auto-Mounting Disk Arbitration automatically mounts disks when connected , which can cause unwanted writes to forensic evidence . You can check if it’s enabled and disable it if needed. To disable Disk Arbitration: sudo launchctl unload /System/Library/LaunchDaemons/com.apple.diskarbitrationd.plist To enable it again: sudo launchctl load /System/Library/LaunchDaemons/com.apple.diskarbitrationd.plist To check if it’s running: ps auxw | grep diskarbitrationd -------------------------------------------------------------------------------------------------------- Boot Camp and Multi-Boot Systems Many Macs have Boot Camp , which allows them to dual-boot macOS and Windows. If you’re imaging a system in Target Disk Mode , be aware that Windows partitions might automatically mount when connected to a Windows system. Some users even triple-boot with Linux using tools like rEFInd . -------------------------------------------------------------------------------------------------------- Tips for Disk Acquisition Live collection  is usually your best bet. Capturing data from a running system avoids many of the challenges mentioned above. Here are a few strategies: Endpoint monitoring tools  like EDR  (Endpoint Detection and Response) are essential for tracking suspicious activity or capturing data. Examples include Velociraptor  or remote access agents like F-Response . Forensic tools : If you have access to commercial forensic software, you’re in good hands. Some commonly used options include: Cellebrite Digital Collector FTK Imager OpenText EnCase Magnet Acquire Direct Access Methods :If you have direct access to the system but not commercial tools, you can still use open-source solutions. dd  or dcfldd/dc3dd : These tools can create a disk image that can be sent to external storage or even a remote address using netcat . Sumuri PALADIN : A live forensic USB tool for capturing disk images. --------------------------------------------------------------------------------------------------------- Lets start what you came for Mounting APFS and HFS+ Images on macOS (With or Without FileVault) If you’re dealing with forensic images on macOS, mounting APFS or HFS+ images is a key step in analyzing disk contents . Whether your image is encrypted with FileVault or not, here’s a simple, hands-on guide to getting it done. Mounting APFS Images (macOS 10.13 and Later) Step 1: Create Mount Points Before you mount an image, create directories to serve as mount points: mkdir /Volumes/apfs_image/ mkdir /Volumes/mounted_apfs/ If you have an E01 forensic image, you need to convert it to DMG using xmount: sudo xmount --in ewf C ollectedimage.E01 --out dmg /Volumes/apfs_image/ Step 2: Attach the DMG Without Mounting Use hdiutil to attach the DMG without auto-mounting: hdiutil attach -nomount /Volumes/apfs_image/Collectedimage.dmg This creates a /dev/disk# entry for the attached image. Step 3: Find the APFS Volume Run: diskutil ap list Locate the correct volume with OS or user data. Step 4: Unlock FileVault (If Encrypted) If FileVault is enabled, unlock the disk: diskutil ap unlockVolume -nomount It will prompt you for the password. Step 5: Mount the APFS Volume Now, mount the APFS volume in read-only mode: sudo mount_apfs -o rdonly,noexec,noowners /dev/disk# /Volumes/mounted_apfs/ Your APFS image is now accessible at /Volumes/mounted_apfs/. --------------------------------------------------------------------------------------------------------- Unmounting APFS Images When you’re done, cleanly unmount the image: diskutil list diskutil eject /dev/disk# mount umount /Volumes/mounted_apfs/ If it refuses to unmount, force it: sudo umount -f /Volumes/mounted_apfs/ --------------------------------------------------------------------------------------------------------- Mounting HFS+ Images Method 1: Using xmount Step 1: Create Mount Points mkdir /Volumes/hfs_image/ mkdir /Volumes/mounted_hfs/ Step 2: Convert and Attach Image sudo xmount --in ewf hfs_Collectedimage.E01 --out dmg /Volumes/hfs_image/ hdiutil attach -nomount /Volumes/hfs_image/Collectedimage.dmg Step 3: Mount the HFS+ Volume sudo mount_hfs -j -o rdonly,noexec,noowners /dev/disk# /Volumes/mounted_hfs/ Now, you can access the mounted volume. Method 2: Using ewfmount If xmount isn’t available, ewfmount is an alternative. Step 1: Create Mount Points mkdir /Volumes/hfs_ewf/ mkdir /Volumes/mounted_hfs/ Step 2: Mount the E01 Image ewfmount hfs_Collectedimage.E01 /Volumes/hfs_ewf/ Step 3: Create a Symbolic Link ln -s /Volumes/hfs_ewf/ewf1 /Volumes/hfs_ewf/Collectedimage.dmg Step 4: Attach and Mount hdiutil attach -nomount /Volumes/hfs_ewf/Collectedimage.dmg sudo mount_hfs -o rdonly,noexec,noowners /dev/disk# /Volumes/mounted_hfs/ Mounting HFS+ 4K Images (With or Without FileVault) Some images use a 4K block size, which requires a different approach. Step 1: Create a Mount point Step 2: Convert to DMG sudo xmount --in ewf hfs_Collectedimage.E01 --out /Volumes/hfs_image/ Step 2: Attach the DMG With 4K Block Size hdiutil attach -nomount -blocksize 4096 /Volumes/hfs_image/Collectedimage.dmg Step 3: Unlock FileVault (If Needed) diskutil cs unlockVolume Step 4: Mount the HFS+ Volume sudo mount_hfs -o rdonly,noexec,noowners /dev/disk# /Volumes/mounted_hfs/ Now your HFS+ 4K image is mounted and accessible. If Commercial Tools Aren’t Available: Mounting the image on macOS  is straightforward, but it requires a few key options: rdonly : Mounts the image as read-only, ensuring no accidental changes. noexec : Prevents any code from executing on the mounted image. noowners : Ignores ownership settings, minimizing access issues. ------------------------------------------------------------------------------------------------------------- Mounting in Linux Mounting an APFS image on Linux is possible but requires FUSE  (Filesystem in Userspace) drivers. Here’s a simplified guide: Install APFS FUSE Drivers : First, you’ll need to install the necessary dependencies and clone the APFS FUSE repository from GitHub. sudo apt update sudo apt install libicu-dev bzip2 cmake libz-dev libbz2-dev fuse3 clang git libattr1-dev libplist-utils -y cd /opt git clone https://github.com/sgan81/apfs-fuse.git cd apfs-fuse git submodule init git submodule update mkdir build cd build cmake .. make ln /opt/afps-fuse/build/apfs-dump /usr/bin/apfs-dump ln /opt/afps-fuse/build/apfs-dump-quick /usr/bin/apfs-dump-quick ln /opt/afps-fuse/build/apfs-fuse /usr/bin/apfs-fuse ln /opt/afps-fuse/build/apfsutil /usr/bin/apfsutil NOTE: ln commands are to make it easier to run the commands without n eeding to add the /opt/apfsfuse/ build folder to the path . This may vary depending on your environment. Mount the Image : After setting up FUSE, you can mount the image using this command: mkdir /mnt/apfs_mount #create mount point cd /mnt/ewf_mount #change to the directory where the E01 file is located. apfs-fuse -o ro,allow_other ewf1 /mnt/apfs_mount # mount the image read only If you want a script to automate this for Debian-based distros   (like Ubuntu), check out the one available at this link. https://github.com/TazWake/Public/blob/master/Bash/apfs_setup.sh ------------------------------------------------------------------------------------------------------------- Final Thoughts In forensic investigations, especially on macOS systems, APFS disk acquisition  can be tricky. Between encrypted disks, System Integrity Protection (SIP), and Apple's tight security measures, your best option is often live data capture. Mounting forensic disk images on macOS, whether APFS or HFS+, takes a few careful steps, especially when dealing with FileVault encryption. With xmount, ewfmount, and hdiutil, you have multiple ways to mount images while keeping them forensically sound. ------------------------------------------------Dean------------------------------------------------------

  • Identifying Malicious Software: A Guide for Incident Responders

    One of the most critical challenges faced by incident responders is the rapid identification of suspicious and malicious software on a computer system. With thousands of files and folders present, security professionals must employ various techniques to detect threats efficiently. This process involves analyzing files, performing live response (examining a system while it's running), and conducting temporal analysis (also known as timelining) to trace malicious activity. However, attackers constantly evolve their techniques to evade detection. Some common methods are: Deleting system logs and file metadata  to erase traces of unauthorized access. Obfuscating malware  by renaming files or modifying execution behaviors to mimic legitimate processes. Using packed executables —these files encapsulate malicious code in an encrypted or obfuscated format to evade detection. Implementing custom encryption techniques  to prevent analysis by traditional security tools. To counter these techniques, incident responders can leverage powerful tools like Sigcheck, file entropy YARA, Maldump, and Capa. These tools facilitate rapid triage and analysis of suspicious files, helping to determine whether further investigation or reverse engineering is necessary. ------------------------------------------------------------------------------------------------------------- Sigcheck: Analyzing Code Signing and Anomalies Sigcheck is a widely used tool from Microsoft's Sysinternals suite designed to analyze executable files, verify digital signatures, and detect anomalies . It helps analysts quickly identify unsigned binaries, which are often associated with malware. Why is Code Signing Important? Most legitimate software is digitally signed, ensuring its authenticity and integrity. However, malware authors sometimes obtain stolen or fraudulent certificates to sign their malicious programs. For example, in 2022, malicious drivers were discovered using stolen NVIDIA certificates. Key Features of Sigcheck: Identify Unsigned Binaries:  Using the -u and -s options, analysts can recursively scan directories for unsigned executables. Check for Suspicious Digital Signatures:  Even signed malware can be detected if issued by an unfamiliar or untrusted entity. I ntegration with VirusTotal :  Sigcheck can perform hash lookups to check if a file has been flagged as malicious by security vendors. Entropy Analysis :  High entropy values often indicate packed or encrypted malware. Sigcheck uses Shannon's entropy scale (0 to 8) to assess randomness within files. Example Usage: E:\Malware discovery tool\Sigcheck>sigcheck.exe -a -c -e -h C:\Windows > Sigcheck.csv OR E:\Malware discovery tool\Sigcheck>sigcheck.exe -a -c -h C:\Windows >output.csv This command scans the Windows directory for unsigned files, potentially revealing malware attempting to blend in with legitimate system files. ------------------------------------------------------------------------------------------------------------- File Entropy • Windows system executables average score: 4 - 6 • Packed or evasive malware average score: 6 - 8 A few things to keep in mind: Legitimate files tend to have an entropy between 4.8 and 7.2. Files with an entropy above 7.2 tend to be malicious. Nearly 30% of all of the malicious samples have an entropy near 8.0 while only 1% of legitimate samples have an entropy near 8.0. Approximately 55% of all malicious samples have a entropy of 7.2 or more versus 8% of legitimate samples. Now if you don't want to download extra tool, you can use sigcheck itself (this tool also give entropy score ------------------------------------------------------------------------------------------------------------- YARA: Signature-Based Detection for Malware Classification YARA is one of the most effective tools for identifying malware based on patterns and signatures. Originally developed by VirusTotal, it has become a standard for cybersecurity professionals. How YARA Works: YARA rules define patterns that malware analysts use to detect threat s. These patterns can be based on strings, regular expressions, or more advanced conditions. Example YARA Rule: rule SuspiciousPE { strings: $mz = "MZ" $string1 = "malicious_code" $string2 = "cmd.exe" condition: $mz at 0 and 2 of ($string*) } This rule detects executable files (MZ signature) that contain suspicious strings related to command execution. Benefits of YARA: Scalability:  YARA rules can be applied across multiple systems for quick detection. Flexibility:  Supports regex and logical conditions for precise malware identification. Automation:  Can be integrated with security solutions for real-time monitoring. Example Usage: yara -r rules.yar C:\SuspiciousFolder or E:\Malware discovery tool\yara-v4.5.2-2326-win64>yara64.exe yara\apt_apt12_malware.yar "C:\Users\Akash's\Downloads" This command scans the folder against predefined YARA rules to detect potential threats. ------------------------------------------------------------------------------------------------------------- Understanding Antivirus Quarantine Mechanisms When an a ntivirus detects a suspicious file, it moves it to a quarantine folder . This prevents the file from executing, thereby neutralizing any potential threats. Different antivirus vendors implement their own formats and security measures to make these quarantined files inaccessible or encrypted . If you have access to the live system, the easiest way to recover these files is by using the antivirus software’s built-in recovery options. However, if you are working with a disk image or a copied folder, things can get trickier. Security researchers have reverse-engineered many antivirus quarantine formats and developed tools to extract these files. Extracts: Avast Antivirus Avira Antivirus Eset NOD32 FortiClient G Data Kaspersky for Windows Server Malwarebytes Microsoft Defender This is where maldump  comes in handy. Introducing maldump: A Powerful Open-Source Tool maldump  is a Python-based open-source tool designed to identify and extract quarantined files from various antivirus solutions. One of its standout features is its ability to scan a mounted disk image (such as a forensic triage image) and detect quarantined files across multiple vendors. Key Features of maldump Automatic Detection : It scans known vendor folder locations and identifies quarantined files. Metadata Extraction : Provides valuable details like quarantine timestamps, file hashes, and original file names. File Recovery : Extracts quarantined files for further analysis. Compatibility : Works with both live file systems and mounted forensic images. How to Use maldump To get started, you need Python installed on your system. maldump is pre-installed , but if you need to install it manually, refer to its GitHub repository . Basic Commands: Identify Quarantine Files: maldump -l /path/to/mounted/image This command lists all quarantined files found in the specified directory. Extract Metadata: maldump -m /path/to/mounted/image -o metadata.csv This saves metadata (hashes, timestamps, etc.) in a CSV file for further investigation. Recover Quarantined Files: maldump -q /path/to/mounted/image -o extracted_files/ This extracts all identified quarantine files to a specified folder. Full Scan and Extraction: maldump -a /path/to/mounted/image -o full_output/ This command performs a complete scan, extracts metadata, and recovers all quarantined files. Important Considerations Permissions : Running maldump with administrator privileges ensures access to all necessary files. Folder Structure : If you only have a quarantine folder, you may need to recreate the expected directory structure for proper extraction. Log Collection : Always collect logs and quarantine folders when performing forensic investigations to avoid missing critical data. ------------------------------------------------------------------------------------------------------------- Using capa for Deeper Malware Analysis Once you have extracted a quarantined file, the next step is to analyze its behavior . This is where capa , an open-source malware analysis tool developed by FireEye FLARE, comes into play. Why Use capa? Malware analysis requires advanced skills, but capa simplifies the process by automatically identifying known patterns and techniques used in malicious software . It disassembles the file, compares it against a set of predefined rules, and generates a human-readable report. https://github.com/mandiant/capa/releases/tag/v9.0.0 Key Features of capa Automated Static Analysis : Analyzes a binary file without executing it. Comprehensive Rule Set : Uses a crowd-sourced database of malware characteristics. ATT&CK Mapping : Maps detected techniques to MITRE ATT&CK for better understanding of attacker behavior. Multiple Formats Supported : Works with executables, shellcode, and memory dumps. How to Use capa Basic Analysis of an Executable E:\Malware discovery tool\capa-v9.0.0-windows>capa.exe "E:\Malware discovery tool\maldump-0.5.0\maldump\maldump.exe" This provides an overview of the malware’s capabilities. Verbose Mode for In-Depth Analysis E:\Malware discovery tool\capa-v9.0.0-windows>capa.exe -v "E:\Malware discovery tool\maldump-0.5.0\maldump\maldump.exe" This displays detailed rule matches within the code. Shellcode Analysis E:\Malware discovery tool\capa-v9.0.0-windows>capa.exe -f sc64 "E:\Malware discovery tool\maldump-0.5.0\maldump\maldump.exe" This analyzes 64-bit shellcode, useful for investigating in-memory threats. Export Results in JSON E:\Malware discovery tool\capa-v9.0.0-windows>capa.exe -j "E:\Malware discovery tool\maldump-0.5.0\maldump\maldump.exe" > out.jsonson This outputs the results in JSON format for further processing. Output: Understanding capa Output The results include: Capabilities (e.g., process injection, file modification, registry manipulation) Malware Behavior Catalog (MBC) and ATT&CK technique references Specific code locations matching known malware patterns One key takeaway is that capa helps identify potential threats but does not provide absolute conclusions. For example, legitimate tools like PowerShell  may exhibit the same capabilities as malware . Therefore, capa’s results should be correlated with other forensic findings. ------------------------------------------------------------------------------------------------------------- Conclusion Mastering the extraction and analysis of quarantined antivirus files is an essential skill for malware investigators and cybersecurity professionals. With maldump , you can quickly locate and recover quarantined files from different antivirus solutions. Pairing it with capa  enables deeper malware analysis, helping you understand the behavior and potential threats posed by extracted files. --------------------------------------------------Dean---------------------------------------------------

  • Equifax to WazirX: Lessons in Cybersecurity Failures

    Case Study I : Equifa Data Breach The 2017 Equifax data breach is one of the most significant cybersecurity incidents in recent history. It exposed sensitive information of approximately 147 million people , including Social Security numbers, birth dates, and addresses. But what makes this breach so noteworthy isn't just its scale— it's the series of preventable mistakes that allowed it to happen. Let’s break down what went wrong and explore what organizations and individuals can learn from this cautionary tale. How It Started: A Missed Opportunity to Patch In March 2017, the U.S. Department of Homeland Security issued a warning about a critical vulnerability—CVE-2017-5638 —in Apache Struts, a widely used web application framework. Equifax was notified and passed this information along to its IT teams, with a directive to patch the software within 48 hours, as per company policy. Here’s the kicker: even though Equifax had a policy in place, the vulnerability wasn’t patched. Internal scans conducted by Equifax failed to identify the vulnerable system. This failure was the first of many cracks in their vulnerability management process. By May 2017, attackers exploited the unpatched vulnerability to gain access to Equifax’s systems . For nearly two months, they quietly siphoned off data . During this time, Equifax remained unaware that anything was amiss. The Detection Delay It wasn’t until July 29, 2017, that Equifax noticed suspicious network traffic on their consumer dispute website. Upon investigation, they discovered the breach and took immediate action to block the activity. The affected web application was taken offline the following day. Unfortunately, by then, the damage was done. What Went Wrong? A Breakdown of Failures Missed Patching Opportunity: Equifax had clear instructions to patch vulnerable software, but poor implementation and oversight led to the vulnerability being missed. Expired Security Certificates: While they had an intrusion detection system in place, its expired certificate rendered it useless for monitoring critical activity. Once updated, the breach was identified quickly—but far too late. Lack of Asset Management: Equifax didn’t maintain an up-to-date database of its software and dependencies. This would have helped identify where Apache Struts was running and ensured it was patched promptly. Data Not Encrypted: Despite holding highly sensitive data, Equifax failed to encrypt critical information like Social Security numbers, usernames, and passwords. Poor Segmentation and Privilege Control: Attackers were able to move freely across systems after gaining access, a clear violation of the Principle of Least Privilege (PoLP). Better segmentation and access controls could have limited the scope of the breach. Short Log Retention: Equifax kept logs for only 30 days , hindering their ability to investigate and understand the full scope of the attack. How Equifax Could Have Prevented This Preventing a breach like this requires more than policies on paper—it demands robust implementation and follow-through . Some steps that could have made a difference: Maintain a Complete Software Inventory: Knowing what software is installed and where it’s running is essential for timely patching and vulnerability management. Improve Vulnerability Scanning: Equifax’s scanning tools failed to detect the vulnerable system. Advanced scanning methods and manual verification could have closed this gap . Encrypt Sensitive Data: Encryption is a no-brainer for protecting critical information. Even if attackers gain access, encrypted data remains useless without the decryption keys. Enforce the Principle of Least Privilege: By limiting access to only what is necessary, organizations can reduce the damage attackers can do after a breach. Proactive Threat Hunting: A dedicated threat hunting team could have spotted unusual data exfiltration patterns before the breach became catastrophic. Enhance Monitoring and Logging: Continuous monitoring and retaining logs for a longer period are crucial for detecting and responding to threats. Why This Matters to Everyone The Equifax breach is a wake-up call for both businesses and individuals. Companies need to take cybersecurity seriously—not just as a technical requirement but as a fundamental part of protecting customers' trust . Individuals, on the other hand, should stay vigilant about protecting their own data by monitoring credit reports, using strong passwords, and enabling two-factor authentication wherever possible. Official Report: https://oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf ------------------------------------------------------------------------------------------------------------- Case Study II : WazirX Data Breach In July 2024, WazirX, a prominent cryptocurrency exchange based in India , suffered a significant security breach resulting in the loss of approximately $230 million in digital assets.  This incident highlights the critical need for robust security measures in the rapidly evolving world of digital finance. Let's explore the details of the breach, the factors that contributed to it, and the lessons that can be drawn to enhance cybersecurity in similar platforms. What Happened? On July 18, 2024, WazirX detected unauthorized transactions amounting to $230 million . The breach was traced back to a compromised wallet, which allowed attackers to siphon off a substantial portion of the exchange's holdings. In response, WazirX promptly halted withdrawals and trading activities to prevent further losses and initiated an investigation into the incident. How Was It Discovered? The breach was identified when WazirX's security systems flagged unusual withdrawal patterns from one of its wallets. Upon closer examination, it became evident that the wallet had been compromised, leading to the unauthorized transfer of funds. The exchange's swift action in suspending operations helped contain the breach, although a significant amount had already been lost. Points of Failure Several factors contributed to the success of the attack: Compromised Wallet Security: The attackers were able to gain unauthorized access to one of WazirX’s wallets. This incident points to potential vulnerabilities in their wallet security protocols, such as: Lack of multi-signature authentication , which requires multiple private keys for transactions to be approved. Inadequate protection of private keys , which may have been leaked, intercepted, or poorly stored. Insufficient safeguards like time-based withdrawal limits or geofencing to add additional layers of security. Inadequate Monitoring: While WazirX eventually flagged unusual withdrawal patterns, the initial unauthorized access went undetected . This lack of vigilance can be attributed to: Weak anomaly detection algorithms  that f ailed to recognize suspicious activity early. Insufficient integration of real-time monitoring tools with the broader security infrastructure. Reliance on periodic checks instead of continuous monitoring. Lack of Immediate Response Mechanisms: The delay in detecting and mitigating the breach suggests deficiencies in incident response protocols , such as: No automated responses  to block transactions or freeze the compromised wallet upon detecting unusual activity. Delayed human intervention, indicating a possible lack of staff trained to act swiftly during security incidents. Absence of a predefined escalation procedure  to address high-priority breaches. What Really Caused the Incident? The root cause of the WazirX breach appears to be a combination of technical and procedural shortcomings: Human Error:  Mismanagement of critical security infrastructure, such as failing to properly secure the compromised wallet or configure monitoring tools, played a significant role. Overlooked Security Fundamentals:  WazirX did not fully implement widely accepted best practices in cryptocurrency security, such as the use of hardware security modules (HSMs) for private key storage. Insufficient Investment in Security:  The breach highlights a lack of prioritization in areas like: Regular penetration testing   to identify potential vulnerabilities. Continuous updates to security systems to keep up with emerging threats. Comprehensive security training for employees handling sensitive operations. Lessons Learned The WazirX breach offers several critical insights for cryptocurrency exchanges and similar platforms: Enhance Wallet Security:  Implement multi-signature wallets and advanced authentication mechanisms to ensure that no single point of failure can lead to a breach. Real-Time Monitoring:  Establish continuous monitoring systems capable of detecting and responding to suspicious activities instantly to mitigate potential breaches. Regular Security Audits:  Conduct frequent security assessments and penetration testing to identify and address vulnerabilities proactively. User Education:  Educate users about security best practices, including recognizing phishing attempts and securing personal authentication methods. Incident Response Planning:  Develop and regularly update comprehensive incident response plans to ensure swift and effective action when breaches occur. Conclusion The 2017 Equifax breach was a wake-up call for the world , highlighting the devastating consequences of neglecting cybersecurity basics. It spurred conversations about data protection, regulatory compliance, and the need for robust security measures. However, as the 2024 WazirX breach painfully demonstrates, many organizations still fail to prioritize security adequately. Despite the lessons from past incidents, breaches continue to occur due to preventable errors like poor configuration, inadequate monitoring, and insufficient protection of sensitive assets. These failures not only jeopardize user trust but also expose organizations to immense financial and reputational damage. It's clear that awareness is not enough . To truly address the growing threat landscape, organizations must adopt a proactive stance on cybersecurity. Dean

  • Part 3 Code Injection : How to detect it and Finding Evil in Memory with MemProcFS FindEvil Plugin

    When it comes to modern cyber threats, attackers are getting craftier with their code injection techniques. The old-school methods are still around, but more sophisticated attackers are now directly manipulating memory structures to blend in and avoid detection. These techniques include modifying memory permissions, hijacking execution pointers, and even patching legitimate code. While this might sound scary, the good news is that we can still detect these attacks—though it requires a deeper dive into how processes manage memory. -------------------------------------------------------------------------------------------------------- Power of Volatility for Detection We can still catch these manipulations using memory forensics tools like Volatility . By comparing multiple memory structures, we can spot inconsistencies that indicate something fishy is going on. A great example of this is the ldrmodules  plugin in Volatility . This tool examines the different ways Windows tracks loaded DLLs and cross-references them with memory-mapped files. Here's what it looks at: Process ID (PID)  and Process Name Base Address  of the DLL in memory Lists from the PEB  tracking loaded DLLs Mapped Path  of the DLL from the VAD tree A legitimate DLL will appear in all these lists and have a valid disk path. If any of these are missing or mismatched, it could indicate code injection. ------------------------------------------------------------------------------------------------------------- Real-World Red Flags Lets take an real world example: We took a closer look at a potentially infected process, powershell.exe (PID: 5352) , using ldrmodules  in our forensic analysis. Right away, we found entries with no MappedPath information . What does that mean? Well, normally, when a program loads a DLL, it gets mapped from disk into memory through standard Windows APIs. But in this case, there was no mapped path to a file on disk — which strongly suggests that the DLLs were injected directly into memory instead of being loaded the usual way. Why is that a red flag? Because malware often avoids writing files to disk to evade antivirus detection and forensic analysis.  If security tools can’t scan files on disk, they have a harder time catching the malware. ------------------------------------------------------------------------------------------------------------- The Process Environment Block (PEB) and More Suspicious Clues Digging deeper, we checked the Process Environment Block (PEB ) —which keeps track of all loaded DLLs in a process. Normally, every DLL should show up in these linked lists, but one particular section (0x6c10000) wasn’t in any of the usual lists. Another section ( 0x7ff78357000 ) was present in most lists except one called InInit . That missing entry in InInit might seem normal at first (because the main process executable isn’t listed there by design). However, the real concern is that i t also lacks a MappedPath to disk . For example, the legitimate msiexec.exe file should have been mapped from C:\WINDOWS\system32\ or C:\Windows\SysWOW64\ but instead, it wasn’t pointing to anything on disk. That’s a seems to be a key sign of process hollowing. ------------------------------------------------------------------------------------------------------------- What is Process Hollowing? Process hollowing is when malware starts a legitimate process, then removes its original code and replaces it with its own malicious code—all without touching the disk . Since the process still looks legitimate from the outside, it can easily evade security tools that focus on scanning files instead of memory. How Do We Confirm This? Using f orensic tools like malfind  (which detects injected memory sections) and ldrmodules  (which identifies suspicious DLLs), we can spot these anomalies. Here’s how: Compare memory addresses  – If the base addresses reported by ldrmodules don’t matc h what dlllist reports, something’s fishy . Look for missing mapped paths  – If a DLL is running in memory but has no corresponding file on disk, it’s likely injected. Use automated detection tools  – Volatility’s HollowFind  plugin (created by Monnappa K A) is specifically designed to detect process hollowing techniques like this. ---------------------------------------------------------------------------------------------------------------- MemProcFS’s FindEvil plugin is a game-changer. It goes beyond traditional scanning methods by digging deep into memory structures to uncover signs of manipulation. Key Plugins in FindEvil PEB_MASQ: Spotting Process Name Spoofing Attackers love to hide in plain sight, and one way they do that is by altering the Process Environment Block (PEB) to fake a process name or file path. PEB_MASQ detects this trick by cross-checking the PEB details with the Virtual Address Descriptor (VAD) tree . If something doesn’t match up, you know you’ve got a problem. PE_NOLINK: Detecting Hidden DLLs Ever heard of DLL injection? This technique lets malware run inside legitimate processes, making detection difficult. PE_NOLINK works similarly to Volatility’s ldrmodules plugin but takes it a step further. It identifies DLLs with PE headers that exist in memory but are missing from the PEB lists. Be mindful, though—false positives happen, especially if memory paging or PEB corruption is in play. PE_PATCHED: Finding Tampered Code Modern malware doesn’t just inject code—it modifies legitimate executable pages to stay hidden. This technique is often used for evading Windows Defender’s AMSI scans. P E_PATCHED detects these changes by analyzing Page Table Entries (PTEs), specifically prototype PTEs that track modified memory pages . While effective, expect a lot of noise—especially from SysWOW64 processes and .NET applications like PowerShell. Beyond These Three: More Cross-Referencing Plugins MemProcFS includes other powerful plugins such as: PE_INJECT:  Finds reflectively loaded PE files in private memory. PRIVATE_RWX/RX & NOIMAGE_RWX/RX:  Flags suspicious memory permissions that could indicate injected shellcode. FindEvil offers a more thorough analysis of injected code . However, Volatility users can supplement their toolkit with the ptemalfind plugin by Frank Block, which also relies on PTE data to detect advanced injections. Understanding FindEvil’s Output FindEvil pulls data from multiple sources, so its output columns can look overwhelming at first. Here are the most useful ones: PID & Process:  Identifies the affected process. Type & Virtual Address:  Shows where the suspicious memory section is located. VadName:  Helps correlate the memory section with known files or structures. PTE Flags & VadFlagsType:  Useful for detecting unexpected permission changes. Adding YARA Scanning for Better Detection One of the coolest upgrades to MemProcFS is its built-in YARA scanning . This allows you to automatically scan memory against known malware signatures. When enabled, YARA matches appear at the top of the FindEvil output, helping you quickly pinpoint malicious processes. ------------------------------------------------------------------------------------------------------------- If you want to learn more about MemProcFS and MemProcFS Analyzer, i have created an complete article with indepth overview which will help you get started link below do check it out https://www.cyberengage.org/post/memprocfs-memprocfs-analyzer-comprehensive-analysis-guide ------------------------------------------------------------------------------------------------------------- Next Steps After Finding Suspicious Memory Sections So, you’ve spotted something shady—what now? Take notes : Document process names, virtual addresses, and anything odd in the VAD. Extract the memory sections : MemProcFS reconstructs files found in memory, storing them in the files and vmemd folders for further analysis. Use a hex editor or malware analysis tools : Open extracted memory sections to confirm whether they contain malicious code. Conclusion MemProcFS FindEvil is an incredibly powerful tool for detecting hidden malware and process manipulation. By cross-referencing memory structures and leveraging YARA rules, it provides an in-depth look at suspicious activity that many traditional security tools might miss. If you’re serious about memory forensics, this tool should be in your arsenal! ----------------------------------------------Deam--------------------------------------------------------

bottom of page