The ZDNet article The first big Internet of Things security breach is just around the corner just smells like unnecessary security fear mongering to me. Fear mongering is, according to Google definitions, “the action of deliberately arousing public fear or alarm about a particular issue.” I used the term “unnecessary” because organizations should already be prepared for rogue and unmanaged devices in their networks.
For the TL;DR crowd, Windows 10 was not recognizing any device flashed with older versions of RfCat firmware. Dominic Spill had already identified the issue and created a pull request to fix an extra byte in the USB descriptor length field. Turns out Atlas had originally added that extra byte so that older Windows versions would recognize the dongles. Thus, RfCat has been updated to address this issue and Windows 10 will now recognize devices flashed with RfCat firmware. The rest of this post will outline the process I took to track down this issue and help get Dominic’s pull request merged.
Windows 10 Not Recognizing YARD Stick One
For the TL;DR crowd, the zbanalyzer.py (ZBAnalyzer) script provides an improved method for conducting analysis of ZigBee networks. It is designed to leverage the ZigBee Scapy functionality implemented within the KillerBee project with augmentation from an updated ZigBee Scapy layer provided by a Scapy-Com fork. The rest of this blog post provides a demonstration of how to use ZBAnalyzer.
Capturing ZigBee Packets with KillerBee
Capturing ZigBee network communications is accomplished using a ZigBee capture device. This is most commonly accomplished using the Atmel RZ RAVEN using firmware initially developed by Joshua Wright as a part of the KillerBee project. Riverloop Security is in the final stages of developing the ApiMote v4 beta which may change that in the near future.
For the TL;DR crowd, GRR Rapid Response can be configured to run on a development or small test network using GRR Docker. The GRR setup requires a repack of the GRR client as described in the repacking the client documentation and installation of the clients as described in the GRR Quick Start: Install the Clients documentation. There are a few caveats to getting it configured so that the GRR Clients can communciate with the GRR Server running in Docker. These steps are covered in this blog post.
In last weeks blog post, Creating a Docker IEEE 802.15.4 Toolkit, I talked about getting Docker up and running to test GRR Rapid Response. Installing GRR Docker is straight foward and outlined by GRRs Getting Started documentation. I will begin from there.
For the tl;dr crowd: I have started a project to consolidate IEEE 802.15.4 testing tools into a Docker image: cutaway/dot15d4_toolkit and a Githut repo: cutaway/dot15d4_toolkit. The Dockerfile in this project is designed to build, install, and run River Loop Securitys version of Killerbee, my implementation of Scapy-com, atlas rfcat, and Josh Wrights Killerzee.
While trying to understand Googles GRR Rapid Response framework I worked with the GRR Docker example deployment. Since I dont have any experience with Docker I decided I needed to understand what the GRR Docker was actually doing to get a grasp of how to communicate with systems running as a Docker container. I figured the best way to do this was to implement a simple Docker container of my own, other than the Docker Hello World.
For the tl;dr crowd: fslogger-yaml has been updated to provide better user interactions relating to outputing data to files or remote UDP servers. The python parser has also been updated to provide analysis of processes detected and the files that were modified. The parser is designed to be modular and easily extended by users.
Last we left fslogger-yaml it did not have a script to easily parse the data and provide analysis of the events. Actually, as I discovered during troubleshooting, last we left fslogger-yaml it did not work properly. Both of these issues have been addressed.
For the “TL;DR crowd,”: fslogger-yaml project page.
The release of EmPyre caused me to start thinking about the Indicators of Compromise (IOC) associated with it being used to interact with a system. The network artifacts, while they do need to be investigated, seem fairly straight forward to me. I am more interested in the system-based IOCs.
Since I’ve been out of the forensic arena for a while, I quickly realized that I have no idea how to track changes to system running OSX. There are, of course, system logs and Apple System Log (ASL) files. These do provide valuable information but they do not track everything. I wanted something that would provide me with enough detail that would assist in the generation of consistent IOCs.
For the “TL;DR crowd,” there is nothing ground-breaking here. This is just a post to document some of the steps that I took to get back up to speed with memory analysis, a how-to.
The other day I was involved with a situation that involved collecting and analyzing the memory of an Apple system. I have to admit, it has been awhile since I’ve collected and analyzed the memory of any system. I was eager to get the memory dump and do a little checking of my own to get back up to speed with the capabilities of tools like Memoryze and Volatility.
The system was a Mac OS X Mountain Lion (10.8) 64-bit system and therefore memory was collected and analyzed with Memoryze for Mac. It was an easy process and produced the results required to gain an understanding of the system at that moment. A quick check of the system call list, using Memoryze, confirmed the OS version.
This is a test post. We will test links and pictures later.
Go forth and do good things, cutaway