Hey, Kids, I heard on the news that an airline pilot spotted plaso's sleigh on its way in from Mountain View...

By Anonymous
...bringing everyone a new plaso release just before Christmas.

Version 1.2.0 the Griswold Edition Released.

The plaso development team is happy to announce the release of plaso, version 1.2.0, the Griswold edition just in time for Christmas. And with it, there are wonderful new features, important bug fixes, better stability and all the other glorious things people have come to expect from each new plaso release.

What's that sound? You hear it? It's a funny squeaky sound... it's the sound of the new plaso 1.2.0 running through a disk image...

Let's jump in and see what Santa is bringing us this year.

What's Changed Since SuperBark?

Version 1.1.0 (aka SuperBark) introduced the first version of dfVFS, which has since then become more stable and has more features, such as Split RAW storage media image and Bitlocker support, albeit the latter has not been added into plaso yet (coming to a theater near you). The source scanner has also been moved away from plaso and into dfVFS, improving support for other tools to make use of it. There have also been several other code refactors that I'm not going to bore the readers talking about, but in short they consisted of a healthy mixture of technical debt as well as increased stability, faster extraction and less memory usage. We are also in the process of making the tool more accessible as a service (more on that later).

Some of the other changes that were worth noting is that we moved the code away from Google Code and to it's new and shiny location on Github. And with that move we added automatic testing using travis-ci and unit test coverage.

One of the issues we frequently came across with version 1.1.0 was sometimes excessive memory usage. After some careful debugging the root cause turned out to be that the storage process couldn't keep up with the parsers, and events were getting queued up. This has been partially addressed in this new release, already showing significantly reduction of memory usage. Next version will include a newly designed storage system that should be considerably faster and designed to keep up with the massive amount of events that come from the parsers (see we are already starting to talk about how glorious the next release will be). Until then you may test out a new feature in the storage library and use JSON to serialize events instead of the default protobufs.

In an effort to make it easier for external developers to contribute code we have created few codelabs, meant to familiarize developers with the parser and plugin interface. This effort has already demonstrated positive impact, leading to new developers submitting code. If you are interested in developing code, the codelabs should significantly lower the bar of entry, so please don't hesitate... check out the codelabs and start writing code.

Another part of the tool that got a significant overhaul is preg, the Windows Registry parsing tool. I highly encourage everyone that does Registry forensics to take a closer look at that. There will be some follow up blog post(s) that discuss preg further, until then explore away. This is yet another area that we can still improve greatly with some user feedback (so if you can't or don't want to code, you can still contribute by providing feedback).

New Parsers

No new release can be ... well released without some new parsers. I'm pretty sure I'm forgetting some of the parsers yet here is a list anyway:
  • Android usage-history (app usage) [Keith Wall]
  • Jump Lists .customDestinations-ms files
  • IIS log parser [Ashley Holtz]
  • PL-SQL developer recall files [Marc Leavitt]

New Plugins

There were also some new plugins added:
  • SQLite
    • Chrome Extension Activity
    • Firefox Cookies
  • OLECF
    • Jump Lists .automaticDestinations-ms files.
  • Windows Registry
    • USB key [Preston Miller]
    • BagMRU (aka ShellBag) support (shell items)
    • SAM hive [Preston Miller]
    • Shutdown key [Preston Miller]
    • Task Scheduler Cache

Other Stuff

Although not a separate section, yet it deserves a mention a new analysis plugin got pushed in, plugin for Windows services. The first version lists them up for easier display, more improvements coming for that plugin shortly.

We didn't just have new and shiny things, we also improved some of the already existing stuff, including:
  • Shell item support in the LNK parser, MRUlist and MRUListEx Windows Registry plugins.
  • Windows Job file, better support for the format
  • Windows Prefetch files, better file format support
  • ... and quite a few bug fixes and minor improvements to other parsers and plugins
I already mentioned briefly before the new feature in the storage library to change the serialization format for event objects. To take advantage of the new format, use the parameter "--serialization-format FORMAT", eg:

$ log2timeline.py --serialization-format json /tmp/storage.dump /cases/mycase/image.E01

This should significantly increase the speed of the extraction phase, so please test it out. I can just hear yourselves saying: "Burn some dust here. Eat my rubber." The reason this is not the default setting for this release is that it has not received as heavy testing as the older protobuf serialization. And in the interest of having the tool more stable instead of faster we opted to keep this as an option for users. It may feel like a membership to the Jelly of the Month Club but it is so much more. It truly is the gift that keeps on giving.

Other honorable mentions is the foreman, which you will notice once the tool is run. This version comes with the initial version of the foreman, which role is to monitor the health of each of the workers. In the future this process will stop and re-start workers that are not functioning properly and better monitor the tools overall health.

In other words if this turkey tastes half as good as it looks, we're all in for a real treat!

Where to Download

The tool is available through the "normal" distribution mechanism. 
  • Pre-compiled binaries are available via Google Drive
  • For Ubuntu systems there are three repositories that can be used:
The minimal repository that contains only plaso and it's dependencies and is always "bleeding" edge, that it gets updated fairly frequently:

sudo add-apt-repository ppa:kristinn-l/plaso-dev

The same equivalent repository but contains more packages related to forensics in addition to plaso and it's dependencies:

sudo add-apt-repository ppa:sift/dev
Or use the SIFT repo that only contains the releases of plaso and it's dependencies:

sudo add-apt-repository ppa:sift/stable


And then to install the actual tool:

sudo apt-get update
sudo apt-get install python-plaso

And one final word, for Mac OS X users, make sure you delete the old packages before installing new ones. Instructions will be put at the tool site shortly.

Comments

Post a Comment

Popular posts from this blog

Parsing the $MFT NTFS metadata file

By
Background Numerous articles have been written about parsing the $MFT NTFS metadata file before. Some of these explain the technique itself [ 1 ] and others mostly focus on how to use tools. Rarely do articles mention the pros and cons of the technique from a digital forensics perspective [ 2 ].  What is $MFT parsing?  For readers not familiar with the NTFS file system, MFT stands for Master File Table. This table is stored in a file system metadata file, meaning that as far as the file system is concerned it is a file, however that the file contains file system metadata not “regular” content. The name of this file is “$MFT”.  The MFT consists of a sequence of (predetermined) fixed-size entries (or MFT entries). These entries are typically 1024 bytes in size, however the size is defined in the NTFS volume header and in a “regular” MFT entry itself.  The first 4-bytes of a “regular” MFT-entry (or record) starts with the signature “FILE”. The MFT entry can...
Read more

Incident Response in the Cloud

By
Many organizations have begun moving a majority of their services towards the cloud in recent years. As a result, attackers have shifted their focus towards the cloud. This has resulted in new techniques and methods specifically designed to compromise cloud infrastructure, like the recent SALTSTACK vulnerability that was widely exploited [ 1 ]. Therefore it is critical for these organizations to have an incident response team that understands the new risks attached to cloud and how cloud can make incident response easier or harder.  In this blog post we will walk you through each phase you may encounter in traditional incident response and highlight the differences when adopting cloud computing. It is aimed towards both those who are new to incident response and cloud computing. We’ve included insights that will benefit organizations taking that step towards cloud who want to ensure they are prepared to respond efficiently to cloud incidents.  Traditional Incident Response Be...
Read more

Container Forensics with Docker Explorer

By Anonymous
  Introduction As previous blog posts on cloud forensics have noted, applications are increasingly being deployed using container orchestration frameworks such as Kubernetes, especially in cloud environments.  Similar to traditional deployments on physical servers or virtual machines (VMs), when a containerised application has a security issue it can lead to a compromise of the underlying compute architecture. In the case of container deployments this means a compromise of the container itself, the container host, or even a wider cluster compromise via abuse of orchestration tools. Often digital forensics is required to establish what went wrong and remediate any issues. This article will provide an introduction to container forensics with Docker Explorer by working through a scenario involving a compromised container running within a Kubernetes cluster. Although Kubernetes is briefly mentioned, this article will focus on analysis of an individual container rather than the wi...
Read more