Forensic Blogs

An aggregator for digital forensics blogs

by

Update: tcp-honeypot.py Version 0.0.7

This new version of tcp-honeypot.py, a simple TCP honeypot and listener, brings TCP_ECHO and option -f as new features.

TCP_ECHO can be used to send back any incoming data (echo). Like this:

dListeners = {4444: {THP_LOOP: 10,THP_ECHO: None,},}

TCP_ECHO also takes a function, which’s goal is to transform the incoming data and return it. Here is an example with a lambda function that converts all lowercase letters to uppercase:

dListeners = {4444: {THP_LOOP: 10,THP_ECHO: lambda x: x.upper(),},}

If persistence is required across function calls, a custom class can also be provide. This class has to implement a method with name Process (input: incoming data, output: transformed data). Consult the man page (option -m) for more details.

And option -f (format) can be used to change the output format of data.
Possible values are: repr, x, X, a, A, b, B
The default value (repr) output’s data on a single line using Python’s repr function.
a is an ASCII/HEX dump over several lines, A is an ASCII/HEX dump too, but with duplicate lines removed.
x is an HEX dump over several lines, X is an HEX dump without whitespace.
b is a BASE64 dump over several lines, B is a BASE64 without whitespace.

 

 

by

Application Analysis Blog 1

What is Application Analysis?

Artifacts are a subject of fascination, full of information from their time and location.  An application leaves markers on systems that often go undetected by the user. These digital artifacts are small bits of information, ranging from profile icons to private messages. This information could be a threat, and it’s crucial that any consumer be aware of their app’s security. This means that if someone else gets into your system, they might be able to unearth info that could allow them to steal from or impersonate you.

The goal of this project is to find out what information remains after one removes an app from the system. Through this, we can learn what programs are secure and prevent any security risks.

Image stating

Browsers and User Privacy

In the first few weeks of the semester, we spent time examining the artifacts left by internet browsers. Through this, we uncovered a treasure trove of information in the “Appdata” folder. This folder is where every desktop application stores it’s information. Because it’s deemed unnecessary for user interaction, the Appdata folder is full of user input for most programs. If a normal consumer stumbled upon this, it wouldn’t mean much to them. However, this is all the juicy bits of data that were part of your account on a program. This could be very useful for someone trying to take control of your accounts.  For example, one of the files within this folder holds your Cookies, small temporary files that are responsible for holding small, session-long pieces of data.  

We took a look at the browser Firefox, made by the company Mozilla. There are three folders under Appdata: Local, LocalLow, and Roaming. The browser stores data that it accesses in a local server so that it can access it again, like your browser homepage.

Your credit card information that was put into Amazon is held in that file, as is your Facebook password. This is a risk for everyone and it needs to be addressed to make users more aware of their safety online and offline.

An image of the information under the Firefox tab in Roaming

An image of the information under the Firefox tab in Roaming

What types of applications will we be looking at? 

After working with browsers, we started researching other applications to investigate.  We decided to investigate Steam, Google Drive, Dropbox, Viber, and Twitter. Steam is a popular gaming PC gaming platform that, as of April 2019, has a billion accounts and 90 million users. It’s important that such a giant in the video game industry keeps its users’ information private. Google Drive is similar to Dropbox, but is better funded and more used. We are curious to see how much of a difference this makes security-wise for each user. Viber is a small Peer-to-Peer (P2P) application for smartphone and desktop use. P2P gives users equal permissions, allowing for fast data movement. Finally, Twitter is a large worldwide social media application that has had a history of insecurity in its system.

Conclusion

During the course of this semester, we will these desktop applications on our virtual machines. Doing this will generate data from the program into the Appdata folder. After this, we will completely uninstall the applications from the system, and investigate the data leftover, analyzing the trail of data to see if one could abuse it.

We will start next week with analyzing our first application, and we will be sure to let everyone know the verdict on our next blog!

 

Stay up to date with Twitter, Instagram, and Facebook by following @ChampForensics so you always know what we’re up to!

 

The post Application Analysis Blog 1 appeared first on The Leahy Center for Digital Forensics & Cybersecurity.

by

Steganography and Malware

I was reading about malware using WAV files and steganography to download payloads without triggering detection systems.

For example, here is a WAV file with a hidden, embedded PE file. The PE file is encoded in the least significant bit of 16-bit integers that encode PCM sound.

I was wondering how I could extract this embedded file with my tools. There was no easy solution, because many of my tools operate on byte streams, but here I have to operate on a bit stream. So I made an update to my format-bytes.py tool.

Using my tool file-magic.py, I get confirmation that this is a sound file (.WAV) with 16-bit PCM data.

And here is an ASCII/HEX dump of the beginning of the file made with cut-bytes.py:

The data chunk starts with magic sequence ‘data’ (in yellow), followed by the size of the data chunk (in green), and then the data itself: 16-bit, little-endian signed integers (in red).

To extract the least significant bit of each 16-bit, little-endian signed integer and assemble them into bytes, I use the latest version of format-bytes.py.

This is the command that I use:

format-bytes.py -a -f “bitstream=f:

With option -f, I specify a bitstream format.

f:

b:0 means that I extract the least-significant bit (position 0) of each 16-bit integer.

j:< means that I assemble (join) these bits into bytes from least significant to most significant (<).

The data starts 8 bytes into the data chunk, e.g. 8 bytes after magic sequence ‘data’. I define this with cut-expression #c#[‘data’]+8:.

When I run this command, and perform an ASCII dump, I get this output for the beginning of the stream:

I can indeed see an executable (MZ), but it is preceded by 4 bytes. These 4 bytes are the length of the embedded file. As described in the article, the length is big-endian encoded. Hence I use a similar command to extract the length, but with j:>, as can be seen here:

The length is 733696 bytes, and this matches the IOCs from the article.

Then I use my tool pecheck.py to search for PE files inside the byte stream (-l P), like this:

MD5 7cb0e1e2cf4a9bf450a350a759490057 is indeed the hash of the malicious DLL encoded in this WAV file.