Daily Blog #689: Feature Usage from Oleg Skulkin

Hello Reader,
       Tomorrow on the Forensic Lunch I've asked Oleg Skulkin to join. I mainly asked Oleg to join because he won last week's Sunday Funday contest and this is a new thing I'm trying to start, having the prior winner to come on and talk about what they did in their research.  Well in the mean time Oleg went ahead and posted up some entirely new research unrelated to any Sunday Funday. Oleg found a new registry artifact called FeatureUsage which appears to track programs that you launch through the task bar.

Now this is not the only source of this data conceivably, it could overlap artifacts like AmCache, UserAssist, Shimcache and Prefetch. But what's interesting about this is that its tracking a specific time of GUI execution, that being from the taskbar. Which means you could potentially get additional times of execution. Maybe I'm missing something and I'll find out tomorrow when Oleg is on the lunch at Noon CDT (UTC -5)!

You can read Oleg's research here: https://www.group-ib.com/blog/featureusage

Also Read: Daily Blog #688 -  How to make AWS EBS Direct Block API Events appear in Cloudtrail

Read More

Daily Blog #688: How to make AWS EBS Direct Block API Events appear in Cloudtrail

Hello Reader,
           If you read the previous post you would know that in my testing the with the AWS EBS Direct Block API I could not find any Cloudtrail logs written. Well John Lukach has taken up the task of figuring out how to solve this by creating a role that the python script can assume that would generate the logs:

https://cloud.4n6ir.com/posts/cloud-4n6ir-fun-2-detecting-api-access-to-ebs-content/index.html

While John has created the ability to log his own accesses to the API I don't believe this will now capture any events from calling the API. So this is one step closer and a pretty neat workaround to capture events that otherwise would be missed but now what I would consider a fix. 

Also Read: Daily Blog #687

Read More

Daily Blog #687: Forensic Lunch schedule for the next 4 weeks

Hello Reader,
       Its taking some work but I'm lining up guests a month in advance now. Here is the schedule for the next four weeks so you can plan out what episodes you want to see

Date	Guest 1	Guest 2	Guest 3	Guest 4
5/1/2020	Brian Marks	Lee Whitfield	Oleg Skulkin
5/8/2020	Cylance/Jim	Jack Farley w/ MEAT	Josh Brunty - Marshall	Sunday Funday Winner
5/15/2020	MVS CTF Winner	Magnet	Sunday Funday Winner
5/22/2020	Mike Cohen	Sunday Funday Winner

Notice something new there?  I thought it would be fun to invite the Sunday Funday winner from the prior week to come on the Lunch to talk about what they did. Oleg Skulkin was willing to be the first and hopefully not the last!


All times will be Noon CDT (UTC -5) With the exception of 5/22/2020 when we will broadcast at 5PM CDT (UTC -5) to let Mike Cohen actually get some sleep.

Remember if you want notifications subscribe to the Youtube channel to never miss a live broadcast: https://www.youtube.com/user/LearnForensics

Also Read: Daily Blog #686

Read More

Daily Blog #686: Want to be on the Forensic Lunch?

Hello Reader,
         Now that the Forensic Lunch is weekly I'm trying to work extra hard to book guests in advance, which I maayyy have been lax about the last year or so. I'm now booked for the next 4 weeks but I'm looking to find new voices, new research and new cool stuff that the community at large wants to see.

So this is your chance. Been watching the Lunch for years? Always thought you had something to say? Email me dlcowen@gmail.com with the subject Forensic Lunch Guest Request and let's get you scheduled and get the word out on what your up to.

Commercial Software Vendors Please Note:
Commercial products are something I let on the lunch when I personally feel that the value they bring is something novel and has value to the community at large. If you send me a product pitch I may need alot more information before agreeing to have you on.

Examples of past vendors:
Guidance software
Accessdata
Magnet
Atola
Demisto
Belkasoft

I have turned away many others, please know that even if you do come on the public chat will be wanting to ask questions you must be prepared to answer.

Also Read: Daily Blog #685

Read More

Daily Blog #685: Sunday Funday 4/26/20 - Windows Timeline Challenge

Hello Reader,
       I hope your enjoying the return of these weekly challenges. I've enjoyed seeing more people understanding that there is so much we don't know and how we together can push things forward. This week we will continue that effort with a change in focus, let's talk about Windows Timeline before moving onto MacOS next week.

The Prize:

$100 Amazon Giftcard

The Rules:

1. You must post your answer before Friday 5/1/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:
Windows Timeline is an amazing source of user data, however like all things it has limitations. Answer the following questions:
1. How long before an action is taken before it is committed to the Windows Timeline database
2. What process and/or service creates the events
3. What call do developers need to make to support it
4. What is excluded?
5. When do events get removed?

Also Read: Daily Blog #684

Read More

Daily Blog #684: Solution Saturday 4/25/20 - ZOOM DFIR Challenge Winner

Hello Reader,
        Another week of competition is concluded and a victor has a emerged. This week we continued the video conferencing artifacts and Oleg Skulkin with his sheer persistence every week has pulled out the win!

The Question:

When looking at Zoom from a DFIR perspective:

1. Where are the artifacts?

2. What format are they in?

3. Can you recover chat history?

4. Can you recover call history?

5. Anything else you can determine?

The Winning Answer:
Oleg Skulkin (@oskulkin)
https://cyberforensicator.com/

Let’s start from artifacts locations. This time I used two devices for testing: a Windows laptop and a macOS laptop.

So, on Windows the artifacts are stored under:

C:\Users\%USERNAME%\AppData\Roaming\Zoom

You can find the following files and folders inside:

The most interesting folder here is data. Here are its contents:

At first glance we can see two DB files, which are SQLite databases, but unfortunately both databases don’t contain much useful information.

The first, zoommeeting.db, contains some info about meetings, including the timestamps in Unix Epoch:

The next database, zoomus.db, should contain lots of juicy artifacts as, according to Procmon, zoom.exe interacted with it very often, but in fact – it’s almost empty. You can collect some general configuration information from zoom_kv table. Another table, zoom_conf_avatar_image_cache, contains paths for conference avatar images located in the same folder. One more table, zoom_actions_logs, contains info about conference actions, for example, screen sharing, audio muting, etc. Other tables in my testing were empty. I tried recover data using multiple forensic tools as well as using hex viewer, but had no luck. It seems Zoom doesn’t want to store anything due to recently uncovered security flaws. 

As for macOS, artifacts are located under:

/Users/%USERNAME%/Library/Application Support/zoom.us

There are two folders inside: data and Plugins.

The data folder contains the same databases as Windows version – zoommeeting.db and zoomus.db, also almost empty.

So? I couldn’t recover neither call, no chat history. Probably, it needs much more testing.

Also Read: Daily Blog #683

Read More

Daily Blog #683: Forensic Lunch 4/24/20 with the Google IR Team (GRR, Timesketch, Turbinia, DTTimewolf, More!)

Hello Reader,
      We had a jam packed Forensic Lunch today with a portion of the Google IR team today talking all about the open source tools they develop, use and support in their work at Google.

Specifically we had :

• Mikhail Bushkov giving a big update on GRR https://github.com/google/grr
• Johan Berggren (https://twitter.com/jberggren) and Kristinn Gudjonsson (https://twitter.com/el_killerdwarf) talking about Timesketch and Data science
• https://github.com/google/timesketch
• Aaron Peterson (https://twitter.com/aarontpeterson) talking about Turbinia
• https://github.com/google/turbinia
• Thomas Chopitea (https://twitter.com/tomchop_) talking about DTTimewolf
• https://github.com/log2timeline/dftimewolf
• Theo Giovanna talking about libcloudforensics aka cloudforensicutils
• https://github.com/google/cloud-forensics-utils/tree/master/libcloudforensics
• Joachin Metz (https://twitter.com/joachimmetz) - Talking about Plaso, libntfs and Libyal
• Plaso: https://github.com/log2timeline/plaso 
• Libfsntfs: https://github.com/libyal/libfsntfs
• Libyal: https://github.com/libyal

Join them on the Open Source DFIR Slack: https://join-open-source-dfir-slack.herokuapp.com/

Read more about what they are doing on the Open Source DFIR Blog: https://osdfir.blogspot.com/

Watch the video below

Also Read: Daily Blog #682 - Linux Kernel Patches for Safe Forensic Imaging

Read More

Daily Blog #682: Linux Kernel Patches for Safe Forensic Imaging

Hello Reader,
        Are you using Linux as your DFIR environment of choice? Many are and for good reason. Linux makes many things easy thanks to the wide variety of open source DFIR tools available, premade distributions (SIFT, Paladin, DEFT, etc...) and the ability to quickly turn evidence into mountable file systems.

However for all the good there are some Linux internals that might be silently tripping you up. The first is something a lot of us have known for awhile. If you mount a journaled file system that Linux supports (ext3/ext4 are good examples) the underlying driver may replay the journal even if you tell it read only.

In addition to this Maxim Suhanov (@errno_fail) is now showing that write blockers that make a device appear to be writeable and actively suppress errors to make the device appear to be working can lead to a different set of issues. In this case the in memory cache will replay the journal and record other changes unless you pass into dd the direct iflag value to tell to skip the write cache in memory and look at the disk itself. This was a new one to me and very interesting. In fact I initially thought this was something the write blocker was doing wrong and asked for the firmware revision only to realize when thinking about it again that the issue is with the write cache itself.

The write cache is not unique to Linux, all modern operating systems do it. But I didn't think to find a way to bypass when disk imaging and I'm glad Maxim brought it up. Maxim documented this in his Github project for his Linux write blocker kernel module:

In-memory modifications

Some changes to a mounted file system made by a file system driver can be cached in memory, although they won't reach a physical drive (with the patch enabled and a block device marked as read-only, of course). In this situation, reading a "modified" data block with a userspace program (e.g. dd or md5sum) will result in inconsistency between data received by a userspace program and data actually stored on a drive, i.e. a userspace program will get the bytes from cache (containing modifications from a driver), not from a drive (no modifications here). Unmounting a file system will bring things back to normal.

If you want to make sure your Linux kernel is really treating a disk read only you can use Maxim's kernel model: https://github.com/msuhanov/Linux-write-blocker#in-memory-modifications

If you want to read the original tweets go here:  https://twitter.com/errno_fail/status/1253363615282991105?s=20

Also Read: Daily Blog #681

Read More

Daily Blog #681: DFIR Discord by Andrew Rathbun

Hello Reader,
        As we are all isolated and looking for more safe social interaction without leaving a permanent public trace (I'm looking at your twitter) it's good to know there are places we can go to talk DFIR with other practitioners in a less formal environment.

Andrew Rathbun has been hosting a DFIR focused Discord server for two years now and it's grown its own community of people who help each other with their DFIR related issues. On the Discord server you'll see that topics are broken into sub-channels allowing you to quickly jump into the sub-discipline of DFIR that you need to discuss while still having access to more general and open channels for discussion.

If this sounds interesting to you and you are already a Discord user click here: https://discordapp.com/invite/JUqe9Ek

Otherwise click here to read more about how to get started.

Also Read: Daily Blog #680 - Apple Unified Audit Logging

Read More