What to do after hack? I would like to show you interesting places in Windows OS that you can have a look at in order to find out, for example, the post-login information, information about what kind of software was running, information about which files were opened, information from NTFS Journal and also a couple of other interesting places which can indicate that something goes wrong. So, in summary, some of the useful places to have a look into when stepping into the investigation.
Place 1: The profile list
What is the first place? Well, the first place, which is maybe quite natural to check, is the profile list. It shows, of course, what kind of users were logging on to the certain box, but that is not really true because the only thing we see over here are profile folders.
Now, what about if we list SIDs from the registry? Are we able to spot different types of SIDs of the users that were previously logging on here? That list is more interesting. It gets a little bit longer. By opening this registry path: SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\, we are able to list also the details regarding the history of what kind of profiles were created here.
One of the new users that we see that we couldn’t see before is a user hacker. This is the place where we can find quite interesting data regarding the history of the profiles. Of course, someone could be smarter and delete this data from the registry totally, but this is something that is worth checking.
Place 2: The Prefetch
Another place that is worth having a look is (of course!) Prefetch. Prefetch is system wide, and can be asked to spot what kind of different types of executables were running in the following operating system. Here are some examples in my Prefetch folder:
Basically, Prefetch files are in the C:\Windows\Prefetch. Whenever we’ve got a PF file, the last date on the file is the one that indicates the last time the file was actually ran was. Now, I can say that I was running WinWord on the 17th of October.
I am going to show you now what is really interesting here.
For analysis, I am going to use our tool: CQPrefetchParser. CQPrefetchParser takes as a parameter a prefetch file to analyze. Eventually, we can specify only the directory that contains the prefetch files. We can also specify the /out where we are able to decompress the PF file. We will use the basic setting here where we will specify the file and then we will specify -a to analyze. Let’s do that.
>>Download the PrefetchParser<<
CQPreferchParser shows us very nicely all the interesting paths that were related with that particular prefetch file. It also shows modules, the different types of DLLs that were loaded when this particular executable was running.
Also, a cool part of it is that you can see a part of the execution history, like how many times notepad.exe was executed and what was the last time I had it opened.
Place 3: Reviewing Remote Desktop Cache (and Introducing RDCache)
In the next part, I would like to show you within my toolkit the tool that we called CQRDCache. It’s a very simple tool. We can load that terminal server client cache which is in every profile. As you can see, it is in Appdata\Local\Microsoft\Terminal Server Client\Cache. This bin file is interesting because we can analyze it a little bit.
>> Download the RDCache <<
If I do decode it, it shows me the pictures in the grid that were collected when we were connecting using remote desktop services or terminal server/terminal client. Basically, we can change the resolution of the grid according to your needs, or sometimes just to make it a little bit clearer.
We can spot over here all the interesting things that someone saw when this person was connecting to the remote server. Of course, it’s not super clear because it depends on how you move the window within the remote session. Well, guess what? I am looking forward to getting your information on what the user could see when the user was connected to the comments under this blog post.
Place 3: Automatic destinations: Spotting Files Opened By A Software
The next thing that I want to show you is related to something that we call automatic destinations. Automatic destinations contain the history of all the interesting files that were ever used, for example, text files, that we were opened by Notepad.
We can connect to C:\Users\ Paula\ AppData\Roaming\Microsoft\Windows\Recent\Automatic Destinations, and if I choose 9B 9C and so on, that is actually the automatic destinations file for Notepad, because these values are all defined for the known software. These identifiers are known, so you can have a reference to any predefined software we can find within the automatic destinations and the identifier they fall under.
Let’s have a look at Notepad. If I click, for example, the first one, what you can see is that I’ve got some type of files being opened. We can spot a much more, of course, if you dig in further.
Of course, not every software that you are using gets known, so then you just need to browse through all of the automatic designations, but some of the identifiers are already pre-defined. As we mentioned, 9B 9C and so on, signifies Notepad.
Place 5: USN Journal
That’s it. The last one that I want to show you is related with NTFS Journal, or USN Journal, which contains the whole history of files being changed.
For the following you can use the script below:
First of all, what we are going to do is to display files metadata. I am displaying right now file hash for these files, and I am grouping them. By running this command, we can clearly see that all of these files are the same.
Of course, over here I am able to spot as well what the last write time is, and we can see that these are all the same. We’ve got 1.txt, 10.text, and so on. These are all the same.
What I want to show you is that when we, for example, run Get-Member for the options that we’ve got related to time to work on the files, we’ve got here creation time, last access time, and last write time. Take a look below.
We’ve got get and set, which clearly indicates that this is not something that we should rely on since we can set creation time, last access time, and last write time. What’s my point? Basically, we are able to change one of those files and let’s have a look what is going to be the setup.
Let me show you one thing in the folder.
As you can see, all these files are the same. What I can do right now is change content for one file. After changing, one file gets a date from 2016. What I will now overwrite that data:
Now all the other files should be exactly the same as 1.txt. For each file, we are changing the last write time, creation time, and last access time, to that particular time. Let’s have a look at the result. As you see, all of my files right now are from the current date. This is something that we cannot rely very strongly because as you see, this is something that can be changed.
If we move further, what we are able to see from the history perspective, and I am going to use, for example, for that purpose fsutil, we are able to read information about the journal. For that, I am going to use fsutil usn readjournal for the F drive, and that gives us a very nice but quite long output about what kind of changes were made on the disk. Of course, that’s a lot of information. On the Internet, you can find a lot of different types of parsers that can help you to parse that data.
What we can spot over here is that file 430.txt, which we had its basic info changed. Here from fsutil usn readjournal, we are able to see basic information which shows that the file was something that someone worked on. Of course, more information can be spotted using a little bit more professional journal analyzer, but I wanted to show you a free option that can at least indicate that something was done with this file. In the worst case, you can stream this data into a text file and then search for the file name and see if this file was in any matter touched. This is usn journal that we are able to analyze.