So what happens if you run across an AppID that's not on one of the lists? Recently Jamie (Twitter: @gleeda) suggested determining the algorithm used to generate AppIDs, but what if the algorithm is a one-way hash, similar to what is used to compute the hashes in Prefetch file names? If that's the case, then having the AppID alone doesn't provide a means for determining the application name (i.e., if the hash is one-way). So, what else can be done?
Well, this would be a great time for timeline analysis. After all, it's unlikely that the only thing you'll want to determine is the name of the application that corresponds to the AppID; it's much more likely that that will be the first (or one) question of several.
When developing your timeline of system activity from a Windows 7 system, you'll likely have Prefetch files, Windows Event Log (EVTX) files, file system metadata, Registry key LastWrite times, time stamped information from Registry values, etc. Also, when you parse the DestList stream from the *.automaticDestinations Jump List files (particularly the one you're interested in), you'll have an MRU/MFU listing that you can add to the timeline. So what you'd normally look for (as with a Windows XP system) is that an entry was added to or modified within the Jump List file around the time that an application .exe was accessed...but wait...by default, Windows 7 (and Vista) doesn't update last access times on files! Holy MFT, Batman! What now?
Or, what happens if the user installs an application, does some stuff, and then deletes the application? Even if the Windows 7 system had been tweaked to update last access times on files, if the application is deleted and the executable file isn't available (MFT entry is overwritten...)...well, you can see where I'm going with this...
There is a solution to determining which application used in both of the above scenarios. One of the forensically interesting aspects of Jump Lists is that they persist on the system even after the application has been removed. We can use other, similar artifacts, such as Prefetch file metadata and UserAssist key entries (which also persist on a system after the application that was launched has been removed) to correlate the necessary information. For example, if a user installed an application (via an MSI package), you'd see that activity in the UserAssist key (as well as the MSI key listing). If they then launched the installed app, you'd also likely (depending upon how it was launched) see that in the UserAssist key, and then you'd see a Prefetch file being created in close proximity to the launch. You should also see the Jump List file being created within close proximity to the UserAssist key and Prefetch file data.
Once the application is removed from the system, you shouldn't see any further modifications to the Prefetch file or Jump List file data. If you found that the application appeared to have been run multiple times, then you should be sure to look to VSCs for additional available time stamped data.
What I hope this demonstrates is how analysis techniques such as timelines not only provide context to the data that you're looking at, but by incorporating multiple data sources, you increase your relative level of confidence in the data itself. Understanding the nature and value of those data sources also means that not only do you understand what should be there, but you can also fill the gaps when something (i.e., an application) is intentionally removed or deleted.
Not taking anything away from your post but this capability of determining execution of a program using data other than access times has been known through similar means for some time.
ReplyDeleteThanks for the mention, Harlan.
ReplyDeleteJamie's suggestion is one that shouldn't be overlooked. I saw her response as well and thought to myself, "well, it definitely would open a lot of doors to find that out." But like you said, the calculation might be similar to a one-way hash, rendering reverse calculation an exercise in futility.
However, as Jamie said, it's probably more important to confirm that the hash is or is not reversible than to compile lists of AppIDs that may not be maintained forever. I suppose the AppIDs would be most suited for cases in which the suspect is not particularly tech-savvy and installs apps to their default locations.
In any case, I'm glad more people are looking into Jump Lists. Great post.
-Dan
Dan,
ReplyDeleteI agree that Jamie's suggestion is indeed important, and I wanted to provide a solution that could be used immediately, while (hopefully) efforts are made to pursue identifying the algorithm and developing a solution that way.
Thanks.
Anonymous,
ReplyDeleteNot taking anything away from your post but this capability of determining execution of a program using data other than access times has been known through similar means for some time.
I'm sure...but the point of the post isn't specifically about determining the execution of a program. It's about identifying which application was run when either the Jump List AppID is unknown, or when the application was deleted.
Besides, is there really anything wrong with saying it again, or pointing out another artifact (Jump Lists) that can be used?
As far as figuring out how AppIDs are calculated: even if an AppID is a one way hash like a prefetch hash this is useful. This is because if you know how to calculate the hash, you can validate the AppID of an unknown application in a jumplist on the fly instead of having to do so manually. If you have several unknown applications this saves a lot of time. Since these AppIDs seem to be stable across systems and they are probably a one-way hash calculated using application name, version and path, it just seems like it would be worth figuring out how the hash is calculated... I also agree that creating these lists is a good start.
ReplyDeleteSorry forgot to add that once you know the algorithm you can programically try variations on the application name, versions, path etc until you create a hash that matches the AppID. Most likely you'd probably know the program name, location and maybe even version if it were still on the acquired disk... That way it doesn't really matter that you can't get the name from the hash itself, you create the hashes and see if one matches... does that make sense?
ReplyDeleteNope, nothing wrong with saying it again. Just decided to add an equally insulting comment about your research as you made about Registry Decoder on your email list. It was a parody of your earlier comment to Andrew Case:
ReplyDelete"Not taking anything away from Andrew's efforts (much applause to him) but this capability has been available through other means for some time. For example, installing the Parse::Win32Registry module adds the regdiff.pl script to your installation."
Anonymous,
ReplyDeleteJust decided to add an equally insulting comment...
How as my comment insulting? I have great respect for the work that Andrew did. I guess you can make anything sound the way you like.
How about providing your name?
@Jamie:
ReplyDelete...you can programically try variations on the application name, versions, path etc until you create a hash that matches the AppID.
This is very true and certainly makes sense. I wrote a little about how one could manually compare the AppIDs, but it's a very roundabout way of finding a match. Once the algorithm is discovered, automation of this process would be a viable option -- subsequently easing the pain of doing a manual, one-by-one check.
I totally agree with you that finding out how these AppIDs are calculated would be a discovery of great value. Thanks for the insight on this; it's great to see this issue from many different angles.
-Dan
If you haven't looked at @Hexacorn's blog post on AppID and Jumplist filename calculation, be sure to look at it. It sheds light on the way AppIDs are calculated; the exact issue we were discussing here a while back.
ReplyDeletehttp://www.hexacorn.com/blog/2013/04/30/jumplists-file-names-and-appid-calculator/