Dan recently posted what has to be one of the most thorough/comprehensive blog articles regarding the Windows shellbags artifacts. His post specifically focuses on shellbag artifacts from Windows 7, but the value of what he wrote goes far beyond just those artifacts.
Dan states at the very beginning of his post that his intention is to not focus on the structures themselves, but instead address the practical interpretation of the data itself. He does so, in part through thorough testing, as well as illustrating the output of two tools (one of which is commonly used and endorsed in various training courses) side-by-side.
Okay, so Dan has this blog post...so why I am I blogging about his blog post? First, I think that Dan's post...in both the general and specific sense...is extremely important. I'm writing this blog post because I honestly believe that Dan's post needs attention.
Second, I think that Dan's post is just the start. I opened a print preview of his post, and with the comments, it's 67 pages long. Yes, there's a lot of information in the post, and admittedly, the post is as long as it is in part due to the graphic images Dan includes in his post. But this post needs much more attention than "+1", "Like", and "Good job!" comments. Yes, a number of folks, including myself, have retweeted his announcement of the post, but like many others, we do this in order to get the word out. What has to happen now is that this needs to be reviewed, understood, and most importantly, discussed. Why? Because Dan's absolutely correct...there are some pretty significant misconceptions about these (and admittedly, other) artifacts. Writing about these artifacts online and in books, and discussing them in courses will only get an analyst so far. What happens very often after this is that the analyst goes back to their office and doesn't pursue the artifacts again for several weeks or months, and by the time that they do pursue them, there are still misconceptions about these artifacts.
Shell Items
This discussion goes far beyond simply shellbags, in part because the constituent data structures, the shell items, are much more pervasive on Windows systems that I think most analysts realize, and they're becoming more so with each new version. We've known for some time that Windows shortcut/LNK files can contain shell item ID lists, and with Windows 7, Jump Lists were found to include LNK structures. Shell items can also be found in a number of Registry values, as well, and the number of locations has increased between Vista to Windows 7, and again with Windows 8/8.1
Consider a recent innovation to the Bebloh malware...according to the linked article, the malware deletes itself when it's loaded in memory, and then waits for a shutdown signal, at which point it writes a Windows shortcut/LNK file for persistence. There's nothing in the article that discusses the content of the LNK file, but if it contains only a shell item ID list and no LinkInfo block (or if the two are not homogeneous), then analysts will need to understand shell items in order to retrieve data from the file.
This discussion goes far beyond simply shellbags, in part because the constituent data structures, the shell items, are much more pervasive on Windows systems that I think most analysts realize, and they're becoming more so with each new version. We've known for some time that Windows shortcut/LNK files can contain shell item ID lists, and with Windows 7, Jump Lists were found to include LNK structures. Shell items can also be found in a number of Registry values, as well, and the number of locations has increased between Vista to Windows 7, and again with Windows 8/8.1
Consider a recent innovation to the Bebloh malware...according to the linked article, the malware deletes itself when it's loaded in memory, and then waits for a shutdown signal, at which point it writes a Windows shortcut/LNK file for persistence. There's nothing in the article that discusses the content of the LNK file, but if it contains only a shell item ID list and no LinkInfo block (or if the two are not homogeneous), then analysts will need to understand shell items in order to retrieve data from the file.
These artifacts specifically need to be discussed and understood to the point where an analyst sees them and stops in their tracks, knowing in the back of their mind that there's something very important about them, and that the modification date and time don't necessarily mean what they think. It would behoove analysts greatly to take the materials that they have available on these (and other) artifacts, put them into a format that is most easily referenced, keep it next to their workstation and share it with others.
Publishing Your Work
A very important aspect of Dan's post is that he did not simply sit back and assume that others, specifically tool authors and those who have provided background on data structures, have already done all the work. He started clean, by clearing out his own artifacts, and walking through a series of tests without assuming...well...anything. For example, he clearly pointed out in his post that the RegRipper shellbags.pl plugin does not parse type 0x52 shell items; the reason for this is that I have never seen one of these shell items, and if anyone else has, they haven't said anything. Dan then made his testing data available so that tools and analysis processes can be improved. The most important aspect of Dan's post is not the volume of testing he did...it's the fact that he pushed aside his own preconceptions, started clean, and provided not just the data he used, but a thorough (repeatable) write-up of what he did. This follows right in the footsteps of what others, such as David Cowen, Corey Harrell and Mari DeGrazia, have done to benefit the community at large.
A very important aspect of Dan's post is that he did not simply sit back and assume that others, specifically tool authors and those who have provided background on data structures, have already done all the work. He started clean, by clearing out his own artifacts, and walking through a series of tests without assuming...well...anything. For example, he clearly pointed out in his post that the RegRipper shellbags.pl plugin does not parse type 0x52 shell items; the reason for this is that I have never seen one of these shell items, and if anyone else has, they haven't said anything. Dan then made his testing data available so that tools and analysis processes can be improved. The most important aspect of Dan's post is not the volume of testing he did...it's the fact that he pushed aside his own preconceptions, started clean, and provided not just the data he used, but a thorough (repeatable) write-up of what he did. This follows right in the footsteps of what others, such as David Cowen, Corey Harrell and Mari DeGrazia, have done to benefit the community at large.
Post such as Dan's are very important, because very often artifacts don't mean what we may think they mean, and our (incorrect) interpretation of those artifacts can lead our examination in the wrong direction, resulting is the wrong answers being provided as a result of the analysis.
1 comment:
Thanks for the kind words and reinforcement, Harlan. All of the feedback that I've received regarding the post is very much appreciated. This feedback suggests that many different people are taking the time out to learn more about the innards of shellbags and how they work. But as you have stated, it shouldn't stop here -- not for this artifact and not for any other forensic artifact. The gears have to keep turning; more people need to know how to most accurately interpret these artifacts. Some artifacts are more complicated than others, but they all have one thing in common: the potential to be misconstrued.
This is why I so strongly encourage people to do their own research in addition to reading and listening to others. As I mention in the post, if you read something or are told something, don't just blindly believe it. Challenge it and do the work on your own to confirm or deny someone else's claim. Following this simple rule will bring you much closer to figuring out how something works at its core.
As investigators who are usually on the clock to get things out the door as soon as possible, we put a lot of trust into tools. We all do it; sometimes time doesn't permit for thorough testing of every single bit of forensic evidence. But that doesn't mean that all testing should be thrown to the wayside. Manual testing is valuable on so many levels. And in the end, you are only hurting yourself by not knowing how something truly works.
Past that, sharing your findings is even more valuable. Not only are you creating a reference for yourself, you are helping to progress the knowledge base for whatever it is that you are researching. As an example, I referenced the research put out by Harlan, Willi Ballenthin, Chad Tilbury, Joachim Metz, and more. Without that research, my post likely wouldn't exist in the form that it does today. This is what motivated me to not only share the findings, but to share the data set used in testing. Because who knows -- someone may test it the same way and find MORE misconceptions or new findings. This is the nature of progress and it is something that should be embraced by more people.
And as you have discussed in previous posts, this all goes beyond just shellbags. Shell items are everywhere; they are noticeably prevalent in a host of different artifacts. Knowing the nature of shell items will help in understanding how to tie many different artifacts together.
After all, all of these things work together to form the big picture. And you can't solve a puzzle with just one piece.
- Dan Pullega (@4n6k)
Post a Comment