Create MacOS.System.IntelligencePlatform.Wifi.yaml

[ydkhatri]

This artifact parses the views.db database, part of Apple Intelligence which provides detailed connect/disconnect events on recent wifi connections.

[scudette]

We generally try to add sqlite artifacts to the sqlitehunter https://github.com/Velocidex/SQLiteHunter

[ydkhatri]

I see the point in trying to keep all sqlite ones in the same artifact. However, it is not conducive to analysis as the results are cluttered in the notebook with too many empty tables (VQL cells). And as we continue to add more items to the sqlitehunter module, it will only get worse. Grouping is also problematic. One may not want to process all MacOS sqlite artifacts.

While this may be a good one for collecting all sqlite files, it's not usable for review/analysis of results. Ideally, we want to review one artifact in one notebook. Any output with more than 2-3 cells is difficult to work with.

We can add this to sqlitehunter, but I'd rather have it independent (or both places) for reasons cited above.

[scudette]

Thanks for this feedback - it is a good discussion to have

1. Having all sqlite artifacts in the same artifact helps collection - the user does not need to remember each and every one of the hundreds of artifacts
2. it is more scalable - we know we dont miss anything but just collecting one artifact
3. Removing boiler code and eliminate subtle bugs - also this allows the same artifact to work on a bunch of precollected files, live system, dead disk etc
4. You make a good point regarding the presentation aspect of how do we present only relevant artifacts

There are two scenarios - the first is:

1. I want to just throw all sqilte artifacts at an endpoint and see what sticks - in this case it is ok to have lots of cells
2. I want to only look for certain artifacts - here I can restrict what to search for in the sqlitehunter parameters and notebook should only show relevant collections

Both these could be addressed in improving the presentation

[mgreen27-r7]

FWIW I agree with @ydkhatri but this is mainly from the barrier of entry to adding to SQLiteHunter for normal users. I think its much easier to write artifacts that fit specific workflow directly, making searchable and easy to find. This should be exactly what we put on the exchange, and leave the SQLiteHunter as curated.

WRT workflow, I think you also want to allow filtering and targeting to enable all the usecases: bulk/preservation, targetted, hunting for IOC etc. I have always thought we need to expand the filters in SQLiteHunter for this, but havent beein doing enough direct IR to need to. I think one filter at add to SQLiteHunter immediately is TargetArtifactRegex which could allow targeting specific artifact in SQLiteHunter.

[scudette]

Thanks. This was added in Velocidex/SQLiteHunter#37

With the SQLite hunter, you can now select just the one rule if you only want that one - or a regex of rules so it is the same as having lots of separate artifacts.