Daily Blog #692: Sunday Funday 5/3/20 - KnowledgeC on iOS Challenge

Hello Reader,
              Another week of fun and challenges! I'm really enjoying seeing all of you get into this and hope I find more time this week myself to do more testing. Let's face it most of us are still at home, so why not turn some of your downtime into DFIR research time! This week we move over to MacOS aka OSX.

The Prize:

$100 Amazon Giftcard
An apperance on the following week's Forensic Lunch!

The Rules:

1. You must post your answer before Friday 5/9/20 7PM CST (GMT -5)
2. The most complete answer wins
3. You are allowed to edit your answer after posting
4. If two answers are too similar for one to win, the one with the earlier posting time wins
5. Be specific and be thoughtful
6. Anonymous entries are allowed, please email them to dlcowen@gmail.com. Please state in your email if you would like to be anonymous or not if you win.
7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post

The Challenge:
KnowledgeC on iOS is a jam packed knowledge resource, but on OSX it seems to be less used. 
1. What does each table in the KnowledgeC database correspond to activity wise
2. What data is logged  in each table
3. What data is not logged
4. Is there a similar datasource that would fill in the gaps?

Also Read: Daily Blog #691 

Read More

Daily Blog #680: Apple Unified Audit Logging

Hey Reader,
           Today I didn't have the time I needed to get a test kitchen done so I decided to take this opportunity to point you towards another great blog you should be reading with a different focus.

Sarah Edwards over at the Mac4n6 blog has started a series on the apple unified audit logging. If you have not been diving deep in your MacOS/Osx/Whatever they call it now analysis by looking into the data that unified audit logs provide your missing out.

Many examiners look at MacOS as a BSD operating system and just look at syslog, forgetting that there is a whole scaffold of another OS layered on top with its own logging. Apple's Unified Audit Logging is a moving target as they are notoriously not backwards compatible, I mean who else force upgrades file systems?

So do yourself a favor and check out Sarah's blog below:

https://www.mac4n6.com/blog/2020/4/19/introducing-analysis-of-apple-unified-logs-quarantine-edition-entry-0

Also Read: Daily Blog #679

Read More

FSEventsParser 3.1 Released

By Nicole Ibrahim

G-C Partners' FSEventsParser python script 3.1 has been released. Version 3.1 now supports parsing macOS High Sierra FSEvents.

You can get the updated script here: https://github.com/dlcowen/FSEventsParser 

Prior versions of the script do not support High Sierra parsing, so it's important to upgrade to the current version of FSEventsParser.

Other recent updates include:

• Better handling of carved gzip files has been added. Invalid record entries in corrupted gzips are now being excluded from the output reports.

• Even more dates are being found using the names of system and application logs within each fsevent file. The dates are stored in the column 'approx_dates(plus_minus_one_day)' and indicates the approximate date or date range that the event occurred, plus or minus one day.

• Script now reads a json file that contains custom SQLite queries to filter and export targeted reports from the database during parsing.

macOS High Sierra 10.13 and FSEvents

With the release of High Sierra, updates to the FSEvents API resulted in the following changes:

• Magic Header: In macOS versions prior to 10.13, the magic header within a decompressed FSEvents log was '1SLD'. Beginning with 10.13, the magic header is now '2SLD'.

• ItemCloned Flag: The ItemCloned flag was introduced with macOS 10.13.  When set, it indicates that the file system object at the specific path supplied in the event is a clone or was cloned. 

•  File System Node ID: Beginning with 10.13, FSEvents records now contain a File System Node ID. 

• e.g. If FSEvents were from an HFS+ formatted volume, this value would represent the Catalog Node ID.

FSEventsParser Database Report Views

Within the SQLite database, report views have been added for common artifacts. The report views are defined in the 'report_queries.json' file. They include:

• Downloads Activity

• Mount Activity

• Browser Activity

• User Profile Activity

• Dropbox Activity

• Email Attachments Activity

• and more..

To access the report views, open the SQLite database generated by running the script using your SQLite viewer of choice. Expand "Views".

FSEventsParser Custom Reports

The FSEventsParser script now exports custom report views from the database during processing to individual TSV files.


The custom report views are defined in the file 'report_queries.json' which is also available on GitHub.

Users can modify the queries or add new ones to the json file using a text editor. Two examples are shown below: TrashActivity and MountActivity.

To add new queries to the json processing list, follow the json syntax shown below. Define the report views within the 'processing_list' array. To add a new item to the array, define:
1) 'report_name': The report/view name.
2) 'query': The SQLite query to be run.

Notes:

• The report name must be unique and must match the view name in the SQLite query. e.g.
• 'report_name': 'TrashActivity'
• 'query':'CREATE VIEW TrashActivity AS ....'

• The query follows standard SQLite syntax, must be valid, and is stored in the json file as a single-line string value.

FSEventsParser Usage

All options are required when running the script. 

==========================================================================
FSEParser v 3.1  -- provided by G-C Partners, LLC
==========================================================================

Usage: FSEParser_V3.1.py -c CASENAME -q REPORT_QUERIES -s SOURCEDIR -o OUTDIR

Options:
  -h, --help        show this help message and exit
  -c CASENAME       The name of the current session, used for naming standards
  -q REPORTQUERIES  The location of the report_queries.json file containing custom report
                    queries to generate targeted reports
  -s SOURCEDIR      The source directory containing fsevent files to be parsed
  -o OUTDIR         The destination directory used to store parsed reports

 Below is an example of running the script.


For more information about FSEvents and how you can use them in your investigation visit http://nicoleibrahim.com/apple-fsevents-forensics/.

If you have any comments or questions, please feel free to leave them below.

Also Read: Daily Blog #525: Office 2016 Backstage Artifact Parser

Read More