Forensic Blogs

An aggregator for digital forensics blogs

by

SIFT Update 2

Introduction

This month at the Senator Leahy Center for Digital Investigation, we started analyzing our data. As a part of the SIFT research team, we used our knowledge of digital forensics to scan through files in order to find artifacts that would help us put our criminal behind bars. After we found artifacts, we went on to conduct keyword searches where we found very useful evidence for our investigation.

Experience

We have learned so much over the past month about SIFT. SIFT allows for artifact gathering, and keyword searching. Artifact gathering involves going into the imaged drive and gathering potentially incriminating files, or anything that could be useful to a digital investigators analysis. Pair that with keyword searching and a strong case can be built and argued in criminal court.

Originally SIFT had major issues in the srch_strings function within Autopsy. This was a major issue because srch_strings is used for keyword searching, an essential part of a digital investigator’s case.  Being new to SIFT was difficult because as a team we did not know how to fix this problem. Eventually, we learned the issue occurred because SIFT runs an older, unsupported version of Autopsy (Autopsy 2.24). The only way to fix this was to import a new version of srch_strings into SleuthKit. After importing the new version, we managed to get keyword searching to work with up to three characters, and on the letter “e” alone, got 3 million hits.

For our project, our data gen had us searing for “cyanide”. Therefore, a keyword search for “cyanide” would be useful in finding files that contain information about the poisoning.

Conclusion

Finding artifacts and searching for keywords are extremely important to a digital investigator. Within the coming weeks, we are going to be recovering deleted files from the disk image. Stay tuned for our next blog about recovering deleted files.

The post SIFT Update 2 appeared first on The Leahy Center for Digital Investigation.

by

Extracting DotNetToJScript’s PE Files

I added a new option (-I, –ignorehex) to base64dump.py to make the extraction of the PE file inside a JScript script generated with DotNetToJScript a bit easier.

DotNetToJScript is James Forshaw‘s “tool to generate a JScript which bootstraps an arbitrary .NET Assembly and class”.

Here is an example of a script generated by James’ tool:

The serialized .NET object is embedded as a string concatenation of BASE64 strings, assigned to variable serialized_obj.

With re-search.py, I extract all strings from the script (e.g. strings delimited by double quotes):

The first 3 strings are not part of the BASE64 encoded object, hence I get rid of them (there are no unwanted strings at the end):

And now I have BASE64 characters, I just have to get rid of the doubles quotes and the newlines (base64dump searches for continuous strings of BASE64 characters). With base64dump‘s -w option I can get rid of whitespace (including newlines), and with option -i I can get rid of the double-quote character. Unfortunately, escaping of this character (\”) works on Windows, but then cmd.exe gets confused for the next pipe (it expects a closing double-quote). That’s why I introduced option -I, to specify characters with their hexadecimal value. Double-quote is 0x22, thus I use option -I 22:

This is the serialized object, and it contains the .NET assembly I want to analyze. .NET assemblies are .DLLs, e.g. PE files. With my YARA rule to detect PE files, I can find it inside the serialized data:

A PE file was found, and it starts at position 0x04C7. I can cut this data out with option -c:

Another method to find the start of the PE file, is to use a cut expression that searches for ‘MZ’, like this:

If there is more than one instance of string MZ, different cut-expressions must be tried to find the real start of the PE file. For example, this is the cut-expression to select data starting with the second instance of string MZ: -c “[‘MZ’]2:”

It’s best to pipe the cut-out data into pecheck, to validate that it is indeed a PE file:

pecheck also helps with finding the length of the PE file (with the given cut-expression, I select all data until the end of the serialized data).

Remark that there is an overlay (bytes appended to the end of the PE file), and that it starts at position 0x1400. Since I don’t expect an overlay in this .NET assembly, the overlay is not part of the PE file, but it is part of the serialization meta data.

Hence I can cut out the PE file precisely like this:

This PE file can be saved to disk now for reverse-engineering.

I have not read the .NET serialization format specification, but I can make an educated guess. Right before the PE file, there is the following data:

Remark the first 4 bytes (5 bytes before the beginning of the PE file): 00 14 00 00. That’s 0x1400 as a little-endian 32-bit integer, exactly the length of the PE file, 5120 bytes:

So that’s most likely another method to determine the length of the PE file.

 

by

Bluetooth Tracking Reboot

New Team, New Goals, Same Tools

Frequent readers of this blog may remember last semester’s Bluetooth Tracking Project. It focused on developing methods to trilaterate the position of a Bluetooth device based off signal strength.

This semester, the goal has shifted. Our team will build and implement a network of stand-alone Bluetooth monitoring devices. We are basing this off of research and methodologies developed last semester. These devices will use publicly available toolsets and low cost hardware. They will collect and report information on Bluetooth devices to a central hub. This will make the findings easy to view.

Tools used last semester are being used for this project. Last semester the Bluetooth team used  blue_hydra and ubertooth in conjunction. Both provided key information regarding the functioning of the trilateration. Because we no longer need the same feedback, we decided to focus on using blue_hydra as the scanning tool. The hardware Ubertooth, and he underlying software library, will still be utilized. This will simplify the scripting process of our project immensely. Unlike last semester, we’ve decided to use the Raspberry Pi model 3 as the base of our sensor nodes. The current team is more familiar with this type of hardware. It’s also compatible with all the hardware and software required for the project. Plus, we have them handy.

 

Current Bluetooth Progress

We started out familiarizing ourselves with our new goals and the research from last semester’s Bluetooth project. We used the installation guide from last semester. This ensured that all our hardware is properly configured. Over the past few weeks, we have focused on testing and configuring the hardware and software. We are progressing nicely. When we have a functioning model, future reports will outline the code.

Another big aspect we have been tackling is creating a server infrastructure for collecting all the data. By nature, the sensor nodes distribute across a large physical area. They will need a way of reporting the data they have collected. We decided to take a more structured approach. We implemented an elasticsearch cluster that the nodes can connect to. Elasticsearch has a wealth of built in features, the biggest being an inherent compatibility with kibana dashboards and the elasticsearch python library. The Elasticsearch Python library ships data from our nodes to our Elasticsearch cluster. Kibana allows us to visualize, manipulate, and collect metrics. This makes it easy to view Bluetooth devices that have been collected from our nodes.

Wrap Up

When laying the groundwork for this project, we took into account previous work. It was important to set up the project in a way future teams would be able to build without making radical design changes. Last semester’s Bluetooth team had thorough methodologies and research. This enabled us to start making infrastructure choices immediately. Our next steps will focus on executing our code outlines and building out the server infrastructure.

Stay tuned for more updates to come and follow us on Twitter @ChampForensics, Instagram @ChampForensics, and Facebook @ChamplainLCDI.

The post Bluetooth Tracking Reboot appeared first on The Leahy Center for Digital Investigation.