Welcoming Yeti to the OSDFIR Infrastructure family

Authored by Thomas Chopitea and Wajih Yassine Overview We are excited to announce that Yeti is now available for use through the OSDFIR Infrastructure project.           What is Yeti? Yeti aims to bridge the gap between Cyber Threat Intelligence (CTI) and Digital Forensics & Incident Response (DFIR) practitioners by providing a Forensics Intelligence platform and pipeline for DFIR teams. It was born out of the friction of having to repeatedly answer questions such as “where have I seen this artifact before?”, “how do I search for indicators of compromise (IOCs) related to this (or other) threats in my timeline?”, “what findings have I found useful in similar investigative scenarios?”. The main goal of Yeti is not only to collect IOCs and Techniques, Tactics, and Procedures (TTPs) like a classic threat intelligence platform, but to also store and deliver DFIR intelligence such as useful queries, artifact locations, and methodologies.  How does Yeti integrate with the rest of the OS

Plaso 20240308 released

Plaso 20240308 released The Plaso team is delighted to announce a new Plaso release, 20240308. This release has a mixture of new features and under the hood improvements. Notable changes Support for Mac OS login window ( #4799 ), startup item ( #4800 ) and login and background items plist plugins ( #4790 ) plist files with thanks to Matthew Pfeiffer ( @Spferical ). Support for Mac OS launchd.log text parser plugin ( #4686 ) with thanks to @rick-slin . Improvements to Windows EventLog resource extraction and message formatting ( #4259 ). Moved data into Python module and migrated tools to Python entry points ( #4769 ). The full list of cleanups, performance tweaks and bug fixes can be found in the release milestone . Upcoming changes in future releases Migrate Docker image to Ubuntu 24.04 once released. Continued work on pre-processing and knowledge base ( #4543 ). Move image export to the dfImageTools project ( #1 ). Where/how to get Plaso 20240308? See Plaso's Users' Guide . T

You can’t Incident Command an email thread

You can’t Incident Command an email thread Copied on February 28, 2024 from with permission. Authored by Matt Linton  For many years I’ve been advocating that the Incident Response community adopt the formal incident management methods outlined in NIMS “Incident Command System” (ICS) and I’m thrilled to say that in recent years that adoption has been spreading and providing real benefits to IR. However, along with the success of any framework come the inevitable “Bad practice” antipatterns. One of these is the general misunderstanding of what an “Incident Commander” is — which spreads mostly through scope creep of a successful framework (ICS) into situations it’s less well-suited for (non-urgent issues and task management). If you want to stop reading here, the TLDR is:  You cannot Incident Command an email thread.  Either your incident is urgent and requires ICS or it’s not, and needs some other pro

Life of a GRR message

Life of a GRR message Authored by Dan Aschwanden and Mikhail Bushkov, copied with permission. Introduction In this article a macro-level outline of how GRR Rapid Response (or GRR) messages are delivered via Fleetspeak as the communication conduit is provided. The details covered in this article will be valuable for scenarios where you need to debug or troubleshoot functionalities of GRR and/or Fleetspeak. Furthermore, the content in this article is also suitable as a first introduction to GRR and Fleetspeak. So whether you only get started or you are a seasoned practitioner we hope you will be able to take away something useful from this article. Fleetspeak does much of the heavy lifting for the GRR message exchange. Its design has some unique networking requirements which we already covered in a previous article . In this article we dive into the nature of the persistent connections that Fleetspeak clients (aka agents like GRR) use to communicate with the Fleetspeak server (aka fron