top of page

Search Results

417 results found with an empty search

  • Analyzing Safari Browser, Apple Mail Data and Recents Database Artifacts on macOS

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

  • Understanding macOS App Preference Files, (MRU) Files Shared File Lists and Account Artifacts for Digital Forensics

    When analyzing applications on macOS, understanding where configuration files, databases, and caches are stored is crucial. These files can provide insights into user activity, preferences, and even location data. Application Configuration Files Application configuration files store essential settings, preferences, and permissions. These are typically found in .plist files, which use the reverse DNS format (e.g., net.whatsapp.WhatsApp.plist). Location for Configuration Files: (~ Means user directory) macOS: ~/Library/Preferences/ ~/Library/Containers/...//.../Preferences/ These files store user-defined settings for applications, making them an essential resource in forensic investigations. ------------------------------------------------------------------------------------------------------------ App Databases and Other Files Many applications store user-generated data, logs, and proprietary files in SQLite databases or other structured file formats. Locations for App Databases: macOS: ~/Library/ ~/Library/Application Support/ ~/Library/Containers/... These databases often contain crucial data such as messages, login details, and activity logs, depending on the application. ------------------------------------------------------------------------------------------------------------ Application Cache Files Caches store temporary data to improve app performance. Although they are less persistent, they can sometimes hold valuable forensic evidence. Locations for Cache Files: macOS: ~/Library/Caches/ ~/Library/Containers/...//.../Cache/ ------------------------------------------------------------------------------------------------------------ Some applications use caches to store location-related data. A good example is the Cache.db file in the Spotlight app. . ------------------------------------------------------------------------------------------------------------- Application Transparency, Consent, and Control (TCC) Applications on macOS require user permission to access system resources like the camera, microphone, and location. These permissions are stored in the TCC.db SQLite database. TCC Database Locations: macOS: User-Level:  ~/Library/Application Support/com.apple.TCC/TCC.db System-Level:  /Library/Application Support/com.apple.TCC/TCC.db MacOS Privacy Settings: TCC.db Analysis For macOS versions 11 and later, the auth_value column replaces the older allowed column: 0 = Unallowed 2 = Allowed You can find records of applications that have been granted access to system files. Location Services Authorization (clients.plist) Location permissions for applications are stored in clients.plist. On macOS, this file is found at: /private/var/db/locationd/clients.plist This file tracks which apps have requested location access, making it useful in forensic investigations involving location data. ------------------------------------------------------------------------------------------------------------- Most Recently Used (MRU) Files When investigating macOS forensics, understanding the Most Recently Used (MRU) files and Shared File Lists (SFL) is essential. These artifacts provide valuable insights into user activity, such as recently opened documents, accessed folders, and used applications. 1. Microsoft Office 365 MRU Storage Microsoft Office 365 applications maintain their own MRU lists in a specific location: Location:   ~/Library/Containers/com.microsoft./Data/Library/Preferences/com.microsoft..securebookmarks.plist Structure:   Each Office application has a separate plist file containing MRUs. Data Stored: Document paths Bookmark data (BLOBs) Unique identifiers (UUIDs) Last accessed timestamps Unlike native macOS MRUs that typically retain only the last 10 items, Microsoft Office applications store significantly more historical data. 2. macOS Finder Recent Folders Finder keeps track of recently accessed folders within a specific plist file: Location:  ~/Library/Preferences/com.apple.finder.plist Key:  FXRecentFolders Structure: The plist contains folder names and bookmark BLOBs. The first entry (Item 0) is the most recent, while Item 9 is the oldest. The GUI order may differ from the plist contents, making direct plist analysis more accurate. 3. Application-Specific Recent Documents macOS applications store recent document lists using the Shared File List (SFL) format. Location: ~/Library/Application Support/com.apple.sharedfilelist/com.apple.LSSharedFileList.ApplicationRecentDocuments/ File Format:  .sfl2 Data Stored:  Recently accessed documents per application Example: com.apple.LSSharedFileList.RecentApplications.sfl2 com.apple.LSSharedFileList.RecentDocuments.sfl2 com.apple.LSSharedFileList.RecentHosts.sfl2 com.apple.LSSharedFileList.RecentServers.sfl2 *.sfl2 5. Understanding NSKeyedArchiver Binary Plist Files Shared File List (SFL) files use the NSKeyedArchiver  format, which is a binary plist structure. These files store serialized data, making them slightly more complex to parse. Key Characteristics: File Extension:  .sfl or .sfl2 (since macOS High Sierra 10.13) Stored Data: $version $objects $archiver (value: NSKeyedArchiver) $top (root of the plist structure) Parsing Binary Plists: Forensic analysts can use the plutil command: plutil -p This converts the binary plist into a more readable JSON-style output. 6. Extracting Bookmark Data Bookmarks in macOS serve as references to files or directories, similar to Windows LNK files. The bookmark data starts with the book (0x626F6F6B) header and contains: File path information Volume name (e.g., Macintosh HD) Volume GUID (Globally Unique Identifier) MacMRU Python Script (To Run on Live System/Mounted Image) https://github.com/mac4n6/macMRU-Parser ------------------------------------------------------------------------------------------------------- Account Artifacts Where macOS Store Account Information macOS account configurations in SQLite databases and plist (property list) files. These files store details about email, calendar, and other connected services. Account Databases macOS 10.11:  ~/Library/Accounts/Accounts3.sqlite macOS 10.12+:  ~/Library/Accounts/Accounts4.sqlite Quick Triage with Plist Files For a quick analysis, investigators can check the com.apple.accounts.exists.plist file located at: /preferences/SystemConfiguration/ (accessible via backups, file system extractions, or physical images). This plist file provides an overview of the types of accounts configured on a device. It contains two key values: Exists:  Indicates whether an account type (e.g., Google, Exchange, iCloud) is present. Count:  Shows the number of accounts for a particular type. ------------------------------------------------------------------------------------------------------------- Exploring Accounts3.sqlite & Accounts4.sqlite Databases These SQLite databases track user-configured accounts and store credentials, descriptions, and identifiers. Investigators can extract useful information from the following tables: 1. ZACCOUNTTYPE Table This table contains the types of accounts configured on the device. Important fields include: Z_PK: Primary key (identification number for each account type) ZACCOUNTTYPEDESCRIPTION: Description of the account type (e.g., Google, Exchange, iCloud) 2. ZACCOUNT Table This table stores details for individual user accounts. Key fields include: Z_PK: Primary Key ZUSERNAME: Account username ZACCOUNTDESCRIPTION: More specific account description ZPARENTACCOUNT: Parent account type (if applicable) ZDATE: Timestamp of account creation (Mac Epoch format) ZIDENTIFIER: Globally unique identifier (GUID) for the account ZKEY & ZVALUE: Configuration key-value pairs (e.g., email servers, ports, authentication settings) ------------------------------------------------------------------------------------------------------------- Forensic Tools for Analyzing macOS On a macOS Analysis Host For analyzing extracted artifacts, forensic examiners can use: sqlite3 / SQLite Viewer  – Database inspection Xcode  – Viewing plist files Virtual Machines  – Controlled analysis environments ------------------------------------------------------------------------------------------------------------- Conclusion Understanding how macOS data is crucial for digital forensic investigations. By analyzing SQLite databases and plist files, investigators can uncover valuable details about user accounts, authentication methods, and linked services. With the right tools and techniques, forensic professionals can extract and interpret this information effectively, aiding in cybercrime investigations and incident response. ----------------------------------------------Dean--------------------------------------------------

  • macOS Tracking Users Activity ,Autoruns Application-Level Firewall and Forensic Insights

    When investigating a macOS system, understanding user accounts, logins, privilege escalations, and screen activity is crucial. Whether you're a forensic analyst, IT administrator, or cybersecurity enthusiast, knowing where to look can make all the difference. ------------------------------------------------------------------------------------------------------------- 🔍 Where Are User Accounts Stored? User accounts and related settings are stored in plist files , which are the backbone of macOS configurations. Key locations include: /private/var/db/dslocal/nodes/Default/users/.plist  → Stores detailed user account info. \Library\Preferences\ com.apple.preferences.accounts.plist   → Contains system-wide account preferences. \Library\Preferences\ com.apple.loginwindow.plist  → Tracks login window settings and user preferences. These files can help identify active, deleted, or even hidden user accounts on a system. ------------------------------------------------------------------------------------------------------------- 🏠 User Logins & Logouts: Who’s Been Using the System? Tracking user sessions helps determine who has accessed the system and when. macOS users can log in through multiple methods: Login Window  → The standard graphical login. Local Terminal  → Using the built-in Terminal. SSH  → Remote access via OpenSSH. Screen Sharing  → Apple’s built-in VNC solution. 🔹 How to Find Login & Logout Events Each login process is labeled USER_PROCESS , and logouts are marked DEAD_PROCESS . These events are logged in system.log, Apple System Logs (ASL), and Unified Logs . Examples: GUI Login ( ( system.log and ASL…also BSM)) Feb 22 15:02:47 Mac loginwindow[95]: USER_PROCESS : 95 console Terminal Login( (10.12 system.log and Unified)) Feb 22 15:29:37 Deans-Mac login[1860]: USER_PROCESS : 1860 ttys000 SSH Login( (10.12 system.log and Unified)) Feb 22 16:29:37 sshd [1831]: USER PROCESS: 842 ttys002 Screen Sharing( (Unified) screensharingd: Authentication: SUCCEEDED :: User Name: deanwinchester :: Viewer Address: 192.168.1.1 By analyzing these logs, you can determine if an unauthorized user accessed the system remotely or via screen sharing. ------------------------------------------------------------------------------------------------------------- 🔓 macOS Screen Unlock Events Even if a user is already logged in, i t’s useful to track whether the screen was locked or unlocked. This can indicate when someone was actively using the system. 🔹 Find Screen Lock & Unlock Events Use the following commands: log show --predicate 'eventMessage contains "com.apple.sessionagent.screenIs"' Locked Screen:   com.apple.sessionagent.screenIsLocked Unlocked Screen:   com.apple.sessionagent.screenIsUnlocked 🔹 How Was the System Unlocked? macOS logs the method used to unlock the screen: Regular Password:  Verifying using PAM configuration screensaver Touch ID:  Using localAuthentication hints Apple Watch Auto Unlock:  Using continuity hints Tracking these logs helps confirm whether the legitimate user accessed the system or if someone bypassed authentication. Note While knowing if the screen is locked or unlocked is good, sometimes you may want to know how a macOS system was unlocked. We can use below query: log show --predicate 'eventMessage contains "LWScreenLockAuthentication" and (eventMessage contains "| Verifying” or eventMessage contains "| Using")' Regular Password: • “Verifying using PAM configuration screensaver” TouchID: • “Using localAuthentication hints” • “Using hint-provided username" • “Verifying using PAM configuration screensaver_la” Auto Unlock with Apple Watch: • “Using continuity hints” • “Using hint-provided username ” • “Verifying using PAM configuration screensaver_aks” ------------------------------------------------------------------------------------------------------------- 🔥 Privilege Escalation: sudo & su Commands Privilege escalation is a key indicator of potential misuse or malicious activity. The sudo and su commands allow users to execute root-level actions. 🔹 How to Detect Privilege Escalation Use these commands to filter logs: log show --predicate '(process == "su" or process == "sudo") and eventMessage contains "tty"' 🔹 What to Look For Terminal Window Used Current Directory User Account Performing the Action Command Executed -------------------------------------------------------------------------------------------------------------------- Ever wondered why some applications launch automatically when you start your Mac? What Are Autoruns? Autoruns are mechanisms that allow applications and services to start automatically when you boot up your Mac or log in. While legitimate applications use these to enhance user experience (like iCloud syncing or antivirus tools), malicious software can exploit them to maintain persistence on your machine. Common Autorun Locations on macOS 1. Login Items (macOS 10.13+) Login Items are programs that launch when a user logs into the system via the graphical interface (GUI) . These can be managed through System Preferences > Users & Groups > Login Items , but not all of them are visible there. Some are stored in system files, making them harder to detect. 📂 Where to find them? ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm (User) .app/Contents/Library/LoginItems/ 💡 Did you know?  Login Items are similar to Windows HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run registry key! 2. Launch Agents  (For Users) Launch Agents are background processes that start when a user logs in . These can interact with the user session and sometimes have a graphical interface. 📂 Where to find them? /System/Library/LaunchAgents/ /Library/LaunchAgents/ ~/Library/LaunchAgents/ 🚨 Red Flag:  If you find unusual or unknown files in these directories, they could be signs of malware! 3. Launch Daemons  (For System-Wide Services) Launch Daemons are similar to Launch Agents but run at the system level, meaning they start before any user logs in and do not interact directly with the user. 📂 Where to find them? /System/Library/LaunchDaemons/ /Library/LaunchDaemons/ 💡 Fun Fact:  Apple’s periodic maintenance scripts, which clean logs and optimize system performance, run using Launch Daemons! ------------------------------------------------------------------------------------------------------------------------- How Attackers Exploit Autoruns Malware authors love using autoruns because they allow persistent infections. Some common techniques include: Placing malicious files in LaunchAgents or LaunchDaemons. Using hidden login items  that don’t appear in System Preferences. Modifying existing system files to automatically execute malware. 🔎 How to Detect Suspicious Autoruns? One of the best tools to inspect autoruns on macOS is KnockKnock  by Objective-See. It scans your system for persistent software, helping you identify unwanted or malicious programs. 👉 Download KnockKnock ----------------------------------------------------------------------------------------------------------------------------- Application-Level Firewall (ALF): Your First Line of Defense Unlike traditional firewalls that manage network traffic at the packet level, macOS uses an Application-Level Firewall (ALF) to control inbound connections for specific applications. ALF determines which apps can receive incoming connections based on their identity. How to Access and Configure ALF Go to System Settings:  Navigate to System Preferences > Security & Privacy > Firewall . Enable the Firewall:  If it’s not turned on, click Turn On Firewall . Customize Firewall Options:  Click on Firewall Options  to fine-tune the settings. Here, you’ll see: Allow signed software  – Lets macOS automatically allow incoming connections for trusted applications. Enable Stealth Mode  – Prevents your device from responding to network probes like ping requests, making it less detectable online. Manually Configure App Access  – Choose which applications can or cannot accept incoming connections. Under the Hood: ALF Configuration File For those who like to dig deeper, ALF’s settings are stored in a property list file  located at: /Library/Preferences/com.apple.alf.plist Here are some key parameters: globalstate: 1  = Firewall enabled, 0  = Firewall disabled allowsignedenabled: 1  = Allow signed software, 0  = Block all by default stealthenabled: 1  = Stealth mode on, 0  = Stealth mode off If you’re a power user, you can tweak these settings manually using the plutil command in Terminal. ----------------------------------------------------------------------------------------------------------------------------- Final Thoughts macOS hides a wealth of forensic. Whether you're a security professional, a digital forensic analyst, or just a power user, understanding these artifacts can give you a deeper grasp of what’s happening under the hood. 🚀 -----------------------------------------------------------------------------------------------------------------------------

  • macOS System Artifacts: macOS Finder, GUI Configurations, Time Changes, Bluetooth, Printing, and Sharing

    macOS Finder Preferences Location:  ~/Library/Preferences/com.apple.finder.plist Finder is the macOS equivalent of Windows Explorer, providing access to files, directories, applications, and networks. The Finder sidebar is customizable and includes: Favorites:  Displays user directories like Documents, Downloads, Pictures, and Music. Locations:  Shows mounted drives such as Macintosh HD, USBs, and disk images (DMGs). The com.apple.finder.plist file stores various user preferences, such as: ✅ Showing mounted servers and hard drives ✅ Column view preferences ✅ Secure empty trash settings ✅ X and Y coordinates of GUI elements These settings provide insights into a user’s workflow, such as frequently accessed directories and how organized they are. ------------------------------------------------------------------------------------------------------------- Saved Application State – Reopen Apps After Restart Locations: 📌 Legacy macOS:  ~/Library/Saved Application State/ 📌 Sandboxed Apps:  ~/Library/Containers//Data/Library/Application Support//Saved Application State/ Since macOS 10.7, the "resume" feature allows applications to reopen exactly as they were before a system reboot or app exit. Each app’s saved state is stored in a dedicated folder named .savedState, containing: windows.plist  (holds window names and positions) data.data  (encrypted session data, including opened files, URLs, and commands) ****Forensic analysts often examine windows.plist files to uncover recently accessed files , websites visited in Safari, or commands executed in Terminal (e.g., sudo, ssh). Even Microsoft Office keeps a history of opened documents here! ------------------------------------------------------------------------------------------------------------- Understanding macOS Time & Date Settings macOS stores time zone and system time preferences in multiple files: 🕒 /etc/localtime – System-wide time settings 🕒 .GlobalPreferences.plist – Stores user-specific time settings 🕒 com.apple.timezone.auto.plist – Automatically detects and sets the time zone These files help macOS maintain accurate timestamps for file modifications, notifications, and system events. ------------------------------------------------------------------------------------------------------------- Time Changes & Location-Based Adjustments Ever wondered how macOS adjusts time zones when you travel? The system relies on location services and network lookups to update time settings automatically. How it Works: macOS uses location services  (if enabled) and network-based lookups  to detect where the system is and adjust the time zone accordingly. The first network connection after traveling  triggers a time zone update. Time zone settings are stored in com.apple.timezone.auto.plist  at /Library/Preferences/ If location services are disabled , macOS relies on timestamps from system logs (/var/log/*) and the symlink at /etc/localtime How to Investigate: Look for logs containing " location"  (location services daemon) or "timezoned"  (time zone daemon). Analyze system log timestamps for sudden jumps. Check /etc/localtime symlink updates , which indicate manual time zone changes ------------------------------------------------------------------------------------------------------------- Tracking Bluetooth Devices on macOS Bluetooth activity can be a goldmine for forensic investigations, revealing which devices were connected and when. Where macOS Stores Bluetooth Data: User-specific devices:  ~/Library/Preferences/ByHost/com.apple.Bluetooth..plist System-wide devices:  /Library/Preferences/com.apple.Bluetooth.plist Organized by Bluetooth MAC address Understanding Timestamps: Last Used Time:  Found under RecentDevices (user) or LastQueryUpdate & LastServicesUpdate (system). First Used Time:  LastNameUpdate (system). However, renaming a device (e.g., AirPods) can reset this timestamp. Logs to Check:  bluetoothd logs provide additional details. Forensic Considerations: Devices can be removed from the cache, making real-time analysis crucial. Apple ecosystem devices (AirPods, iPads, etc.) may connect automatically through Continuity, even if not manually paired. ------------------------------------------------------------------------------------------------------------- macOS Printing Artifacts: What’s Left Behind? Every print job leaves digital footprints in multiple locations on a macOS system. Key Files to Examine: Printer settings:   /Library/Preferences/org.cups.printers.plist Printer configurations:   /etc/cups/printers.conf and /etc/cups/ppd/ (PPD files store printer capabilities) Print Job Metadata: Stored in /private/var/spool/cups/ Print control files (c#####) contain : Printer name User account that printed the job Job name (file/document title) Application used (e.g., Safari, Word) Print data files (d#####-001) store the actual content (usually as PDFs) ------------------------------------------------------------------------------------------------------------- macOS Sharing Preferences: What’s Accessible? Sharing settings determine what resources are accessible on a Mac . Even if features are disabled, historical data can reveal past configurations. Where to Look: Main settings file:   /private/var/db/com.apple.xpc.launchd/disabled.plist 1 = Yes 0 = No Important bundle IDs: ( If the bundle ID for the service does not appear in this list at all, it was likely not checked ever in the past and therefore never enabled.) com.apple.screensharing → Screen Sharing com.openssh.sshd → Remote Login (SSH) File Sharing Data: Located in /private/var/db/dslocal/nodes/Default/sharepoints/ As per screenshot, test folder is shared Shows shared folders, permissions, and network access settings. Look for services like com.apple.smbd (SMB file sharing) or com.apple.AppleFileServer  (AFP file sharing). Forensic Takeaways: Even if a service is currently disabled , historical configurations may indicate past activity. Files shared over the network might still be accessible through logs or cached settings. ------------------------------------------------------------------------------------------------------------- Understanding macOS Screen Sharing macOS comes with a built-in Screen Sharing applicatio n that allows users to remotely access another Mac using the VNC (Virtual Network Computing) protocol. Unlike regular applications found in /Applications this utility is tucked away in /System/Library/CoreServices/Applications It can be incredibly useful for troubleshooting, remote assistance, or even managing multiple machines. When a user enables Screen Sharing  or Remote Management  in the Sharing preferences pane, macOS generates a file called com.apple.RemoteManagement.plist in /Library/Preferences/ This file stores configuration settings that determine how remote connections are handled. ------------------------------------------------------------------------------------------------------------- VNC Access and Credentials If VNC access is enabled , another important file comes into play: /Library/Preferences/com.apple.VNCSettings.txt This file contains an XOR-encrypted password used for VNC authenticatio n. Script to recover password: cat com.apple.VNCSettings.txt | perl -wne 'BEGIN { @k = unpack "C*", pack "H*", "1734516E8BA8C5E2FF1C39567390ADCA"}; chomp; @p = unpack "C*", pack "H*", $_; foreach (@k) { printf "%c", $_ ^ (shift @p || 0) }; print "\n"' ------------------------------------------------------------------------------------------------------------- Tracking SSH Connections: known_hosts File For users who prefer command-line remote access, macOS also supports SSH (Secure Shell). The system records SSH connections in ~/.ssh/known_hosts (or authorized_hosts). This file logs previously accessed remote machines using a combination of IP addresses, hostnames, and public keys. However, if the HashKnownHosts setting is enabled in /etc/ssh/ssh_config , this data is stored in a hashed format, making it difficult to retrieve the original hostname or IP address. ------------------------------------------------------------------------------------------------------------- Terminal Command History: The Hidden Treasure macOS keeps track of commands executed in the Terminal through history files stored in each user’s home directory: ~/.bash_history (for older macOS versions and users still using bash) ~/.zsh_history (default shell starting from macOS Catalina 10.15) These plaintext files log user-entered commands, which can provide valuable insights into: Applications and scripts the user executed Privilege escalation attempts (e.g., sudo usage) Accessed files, directories, and mounted volumes Remote systems or networks the user interacted with Key Considerations The history file is not updated in real-time —it only writes data upon user logout. Commands lack timestamps. Live response tip: You can view an active session’s history using the command: history This will display the command history for the currently logged-in user across open Terminal windows. ------------------------------------------------------------------------------------------------------------- Session-Based History: ~/.zsh_sessions/.history With the introduction of zsh in macOS 10.15, Apple also brought back session-based history  under ~/.zsh_sessions/. Each session gets a unique GUID-based history file, containing executed commands along with timestamps. Unlike .zsh_history, these session logs include file system timestamps and are only deleted after a few weeks. However, similar to .zsh_history, they are only written when the Terminal session is closed. ------------------------------------------------------------------------------------------------------------- Final Thoughts macOS hides a wealth of forensic data in plain sight. Whether you're a security professional, a digital forensic analyst, or just a power user, understanding these artifacts can give you a deeper grasp of what’s happening under the hood. 🚀 --------------------------------------------------Dean------------------------------------------------------

  • 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----------------------------------------------------

bottom of page