Sunday, July 5, 2015

Windows 10 - Analyzing "" prefetch file - winprefetchview

In the first post we got a quick insight into understanding Windows prefetch. In the second post  we did a detailed analysis using the raw hex data within the " file. In this post we will simply use a tool "winprefetchview"

Once the tool has been executed we see the following.

From the above we see the filename, created date, modified date, file size, process, path, run counter, last run time, etc. This basically eliminates the need for most of the work we did in the previous post. However, it is import that we understand what transpired in that post.

That's it for the Windows 10 prefetch series.


Windows 10 - Analyzing "" prefetch file

In the previous post we painted a scenario. In this post we will continue where we left off.

The Windows 10 prefetch file is compressed, thus trying to read it like a Windows 7 or earlier prefetch file is not possible. As a result, we have to put in some work to learn about it. Let's do just that!

Putting in work!
Thanks to some excellent research done by the people in the references, our job has been made somewhat easier.

First let's decompress "". To do this we will use a python script "" which is in the reference section. .

Now that we have the "" decompressed to "". Let's see what strings of interest are related to FileZilla.

We can see that the file was run from "\VOLUME{01d0afe55dc4b8c4-8e60ce0c}\USERS\SECURIYNIK\DESKTOP\FILEZILLA_3.11.0.2_WIN32\FILEZILLA-\FILEZILLA.EXE"

This already is an indication that yes, we are making progress and that this file was actually executed.

Let's dig deeper.

Verifying the name of the executable which was run.
The above executable "FILEZILLA.EXE" clearly matches with the ""

Verifying the hash of file

From the above, the hash presented in the hex "09 9B 85 93" also matches the hash which is found in the filename. Note the byte order was reversed, so
"09 9B 85 93"  became "93 85 9B 09".

Size of the .pf file?

The size of the file is reported "E0 43 01 00". Let's convert this to decimal. Note we need to once again change the byte order. This time "E0 43 01 00" becomes "00 01 43 E0". When converted this gives us "82912".

Let's compare the decompressed file size with what Windows provides us for its properties.

Looking at the size we calculate and the size reported by Windows, it is safe to conclude that the file size is "82912" bytes

Number of times it was executed?

Let's find out how many times this program was executed.

From the above we see the "FILEZILLA.EXE" ran 1 time as show by hex "01 00 00 00"
What time program was executed?

So far we know the program ran. However, if we knew what time it ran this  information may help us to perform some correlation to get a clearer picture.

From the above we see the timestamp "F1 8C 8C E9 C8 B6 D0 01". Similarly to the previous cases, we need to change the byte order before we convert this to decimal. So the new hex value is "01 D0 B6 C8 E9 8C 8C F1". Once converted to decimal the value becomes "130805363221761260". This value is the time in epoch. Using an online calculator we get the time as follows:

From the above we have the execution time as localtime "7/4/2015, 10:18:42 pm".

Awesome!!! Now we have a much clearer picture as to what may have transpired. 

Next step would be to check any network logs, full packet capture devices and or flow data you may have to understand WHAT was sent, the WHERE and the WHY. We already have the WHEN, HOW and potentially WHO. 

Most of what was just done could be easily done with tools such as "WinPrefetchView" or some other tool which perform similar operations. However, remember, knowing how the tool works is much more important than knowing how to work the tool :-)

In the next post we will take a quick look at



Windows 10 Prefetch - Solving the puzzle

In this scenario there is a suspect case in which a user may have exfiltrated data via FTP. However, upon looking at the computer's control panel, there is no FTP application installed. Looking in the program files directory, there is no sign of an FTP application. So what do we do next? I'm glad you asked!

What is the prefetch?
According to Microsoft "Each time you turn on your computer, Windows keeps track of the way your computer starts and which programs you commonly open."

Checking to see if prefetch is enabled.

From the above we see the registry  entry "EnablePrefetcher" with a value of 0x3.
A value of 0x3 means "Application launch and Boot Prefetching enabled"

Additional options.
0 – Disable Prefetcher
1 – Application launch Prefetching enabled
2 – Boot Prefetching enabled

Now that we know that prefetching is enabled, let's look to see what entries may be there.

Boom!! There it is, we have an entry for FileZilla.

Now at least we know while there is no FTP application installed, a FTP application was executed.

Now let's look at the next post to see what else we can learn about its execution.


Saturday, July 4, 2015

Hashing The Good, The Bad and The Similar - ssdeep

The Similar!!

In the first and second post within this series we looked at the good and bad about the typical hashing.

In this post we will look at identifying similarities between two files we already know are not the same. However, what would be helpful is if we knew how similar they are. This information is quite helpful when dealing with polymorphic-code.

Let's get cracking

Revisiting the existing hash. Here are our two files with different hashes.

How Similar
Using a tool like ssdeep we can learn about the similarities of these files

Let's see what the files generate for ssdeep

Comparing the similarity
root@securitynik:~# ssdeep -bvp hashing_lab.txt hashing_lab.txt.copy

Ok then as we can see from the output above, these files match 99%. That is quite a match and obviously help us to understand that these 2 files are clearly related even though they are not the same.


Hashing The Good, The Bad and The Similar

The Bad!!

In the previous post we identify the good in hashing. In this post we will focus on the bad.

The two files we are using are "hashing_lab.txt" and "hashing_lab.txt.copy".

In the previous post we also identified that the 2 files are an exact match, so we can confirm the integrity of these files. I will show it here again for clarity.

Simply change any one character (byte) and the hashes of this file differs completely.
Let's add the letter "z" to the file ""hashing_lab.txt.copy"" to see how this one character changes the hashes.
root@securitynik:~# echo "z" >> hashing_lab.txt.copy

Verifying the new hashes
root@securitynik:~# md5sum hashing_lab.txt.copy
f5762153ed2a7aa6e01ee0d90018567f  hashing_lab.txt.copy

As we can see the hash above is now different from that of the original file.

Let's now put these 2 files together to see the results up close and personal.

From the above we see that the two files differ. Now while this may be good to confirm that two files are not the same, it in no way tells us if they are similar. Similarity becomes important when dealing with Polymorphic code.

See you in the next post on Similarity.


Hashing The Good, The Bad and The Similar

The Good!!

In most cases we use hashing for verifying integrity. However, there are situation in which we are not so much concern about whether 2 files are the same but more about their similarity.

Let's dig deeper. For the purpose of this post I will make a copy of my "/var/log/user.log" file and name it "hashing_lab.txt". You may ask why I choose this file basically, I need a file with at least 4K to complete this scenario. This file will have more than that so that's good enough.

Let's verify my file size

root@securitynik:~# ls -al hashing_lab.txt

From the above we see the file "hashing_lab.txt" has a size of 9612 bytes. This is good enough for us.

Let's move on.

As mentioned previously hashing is typically used for verifying integrity. So let's take a md5 hash of our file "hashing_lab.txt"
root@securitynik:~# md5sum hashing_lab.txt

This returned the following

93c3baaa84c734f343136851b75db1a7  hashing_lab.txt

now let's take a copy of this file

root@securitynik:~# cp hashing_lab.txt hashing_lab.txt.copy

From this copied file, let's grab the hash

root@securitynik:~# md5sum hashing_lab.txt.copy

From the above we get the result

93c3baaa84c734f343136851b75db1a7  hashing_lab.txt.copy

Let's put both files together for clarity.

From this perspective we can see the good of hashing. We were able to verify the integrity of these files are intact. Basically "hashing_lab.txt.copy" is an exact copy of "hashing_lab.txt"

See you in the next post for the bad.