There's been some discussion of late in various corners of the DFIR community regarding "sharing" amongst those of us in the community. Some of it has centered on sharing of threat intelligence and IOCs, and that's sort of spawned off into sharing "case studies". I ran across a couple of threads on one online forum (like this one...), where an interest in case studies was expressed, but as is usually the case, few are actually stepping forward to provide them.
My hope is that these discussions have formed a crack in the wall of silence, and that some of us can squeeze our fingers into that crack, and with the help of others in the community, pry it apart.
Andrew Case posted an excellent case study on the DFS blog, one that is truly inspiring. Andrew looked at what he wanted to do and used what was available to him to get it done.
Corey Harrell has posted a number of times to his blog regarding exploit artifacts, and has taken up a series of posts on accessing Volume Shadow Copies. Corey provided some excellent material which he graciously allowed me to incorporate into chapter 3 of WFAT3e, and he has since taken that several steps further. While not specifically related to cases Corey has worked, this is some excellent information that is of significant value to anyone who encounters Vista and Win7 systems.
Recently, Melia post on a "case experience" to her blog, where she had to address an issue of sploitation. I've had similar cases, and I've had issues where such a thing was just part of the case...and I think what Melia's post really points out is that Windows does a great job of illustrating Locard's Exchange Principle; that is, when the user or an application interacts with the operating system, there are very often artifacts of that interaction that survive attempts by the user to cover their tracks.
From a link in Melia's blog post, I found out about the Cheeky4n6Monkey blog, which has some excellent posts, including this one on creating a RegRipper plugin for CCleaner, which actually covers two topic areas: artifacts associated with running CCleaner, and writing a RegRipper plugin. The author correctly points out that I covered how to write RegRipper plugins in WRF.
There are even more examples available of how analysts have pursued real-world cases. Take a look at this post to the Mandiant blog by Nick Harbour, from July, 2010.
I know from experience (in the industry, writing books, etc.) that many of us really enjoy reading or hearing case studies, but the fact is that few of us actually share case studies, or just some portion of our experiences (I won't get into the "why"...). From recent experience, this is disheartening when you go to a conference where many of the presentation titles lead you to believe that case studies or experiences will be shared, but all you get during the presentations, and even out in the common areas between presentations, are blank stares.
No one of us is as smart as all of us. There are some of us who've seen a lot of things, but no one has seen or done everything. Sharing what we've seen through presentations and blog posts is a great way for us to learn, without having to have had the actual experiences.
Showing posts with label case study. Show all posts
Showing posts with label case study. Show all posts
Saturday, February 18, 2012
Friday, March 27, 2009
Case Studies
The guys over at the Hacking Exposed Computer Forensics blog have been posting a couple of entries that may be of interest to examiners and analysts, called What did they take when they left? In today's economy, and particularly with the news media talking about disgruntled employees taking data or information with them when they leave an employer, this information can be very helpful. Their first post refers to looking for artifacts of CD burning, and part 2 discusses what you might find in the UserAssist key. These are both excellent posts that present more than just dry technical data to the reader...they discuss how the data can be used.
There are some good points raised in part 2, particularly what might have happened if there are no entries in the UserAssist key for the user you're looking at. Based on my experience, one thing I'd point out is to be sure you're looking at the hive file for an ACTIVE user. I can't tell you the number of times that I've seen someone try to run extraction tools across an NTUSER.DAT file from the "Default User" or from the "All Users" profile. I've also seen seasoned examiners try to run tools against the ntuser.dat.log file.
Another point I'd like to expand a bit is that if there are no entries beneath the Count key, or if there don't seem to be a number of entries commensurate with the apparent user activity, be sure to check the LastWrite time of the Count key (particularly if the key has no values at all). Remember, the LastWrite time of a key is similar to the last modification times for files, and the time may correlate directly to when the entries were deleted.
Speaking of which, if you're examining a Windows XP system, don't forget to consider System Restore Points. While the user may have deleted the UserAssist entries from the current hive file, there may be a number of Restore Points that contain valuable data. The upcoming Windows Forensic Analysis second edition includes a discussion of a tool that I wrote to allow the examiner to run RegRipper plugins across the System Restore Points.
Be sure to continue following the posts over at the Hacking Exposed Computer Forensics blog. Folks love a good story, particularly something that they can follow and actually use, and the HECF guys are bringing it on!
Be sure to check out Matt's interview on the Forensic 4Cast podcast, Hogfly's use of HBGary Responder, and Christine's updates at the e-Evidence site.
There are some good points raised in part 2, particularly what might have happened if there are no entries in the UserAssist key for the user you're looking at. Based on my experience, one thing I'd point out is to be sure you're looking at the hive file for an ACTIVE user. I can't tell you the number of times that I've seen someone try to run extraction tools across an NTUSER.DAT file from the "Default User" or from the "All Users" profile. I've also seen seasoned examiners try to run tools against the ntuser.dat.log file.
Another point I'd like to expand a bit is that if there are no entries beneath the Count key, or if there don't seem to be a number of entries commensurate with the apparent user activity, be sure to check the LastWrite time of the Count key (particularly if the key has no values at all). Remember, the LastWrite time of a key is similar to the last modification times for files, and the time may correlate directly to when the entries were deleted.
Speaking of which, if you're examining a Windows XP system, don't forget to consider System Restore Points. While the user may have deleted the UserAssist entries from the current hive file, there may be a number of Restore Points that contain valuable data. The upcoming Windows Forensic Analysis second edition includes a discussion of a tool that I wrote to allow the examiner to run RegRipper plugins across the System Restore Points.
Be sure to continue following the posts over at the Hacking Exposed Computer Forensics blog. Folks love a good story, particularly something that they can follow and actually use, and the HECF guys are bringing it on!
Be sure to check out Matt's interview on the Forensic 4Cast podcast, Hogfly's use of HBGary Responder, and Christine's updates at the e-Evidence site.
Thursday, November 16, 2006
Case Study from SecuriTeam
Everyone loves a case study! Don't we love to read when someone posts what they did when they responded to an incident? It's great, as it gives us a view into what others are doing. SecuriTeam has not one, but two such posts...well, one post that contains two case studies.
The first is a PDF of the incident write-up for a compromise that occurred in July 2006. The second is a follow-up, and both are very interesting.
I'm going to take a process-oriented view of things. Please don't ask me if someone who defaces web pages and knows some PHP code qualifies as a "cyber-terrorist". I don't want to get mixed up in semantics.
This whole thing seems to have started on or about 11 July 2006 with a web page defacement. Evidently, the bad guys gained access to a vulnerable system (found via Google) and installed a PHP 'shell'. Page 8 of the write-up specifies the need for a "real-time forensic analysis", due to the fact that not only did the good guys need to "stop the bleeding", but they had to counter the bad guys, who were not only deploying their own counter-measures, but attacking the good guys, as well. What's interesting about this is that on page 8, the authors mention having to battle active attacks from the bad guys, saying it was a "fight between the attackers...and the incident response personnel." Oddly, pages 9 - 11 included the 12 steps that the IR personnel went through, yet nothing was mentioned about having to battle an attack. The document continues into "Attack Methodology" and "Conclusions" with no mention of IR personnel being hammered by attacks from the bad guys.
Another interesting point is that the authors mention that the user-agent found in some web logs included the term "SIMBAR", and concluded (with no supporting info) that this meant that the attacker's system was infected with spyware. While I'm not discounting this, I do find it odd that no supporting information was provided. I did a search and found references to adware, but I also found a reference to the SIMS game, as well.
Continuing along into the follow-up report, "SIMBAR" is mentioned again, and this time the authors seem to believe that this user-agent indicates that the same computer was used in multiple attacks. IMHO, this is perhaps dubious at best, particularly if it is indicative of adware...adware can be fairly widespread. Also, beyond that, I'm not sure how significant this information really is to the overall incident.
Overall, both write-ups seem to indicate that the attackers used known exploits to gain access to systems, and used relatively known and easily available tools to gain their foothold. It also seems that the authors made several unsupported assumptions. At first the write-ups are interesting read, but when you really try to dig into them and get some meat, IMHO, it just isn't there.
But hey, who am I? What do you think?
Addendum 18 Nov: Besides the comments here, there's been corresponding posts over on TaoSecurity. I just want to say that I'm not trying to grill the authors of the documents, nor am I trying to point out every little detail that I think was mishandled...not at all. What I am saying is that I think the authors did a great job, but there are things that could have been handled a bit better. Richard Bejtlich mentions "focus and rigor" in one of his recent posts...just because something is done by volunteers, does that mean that quality should suffer?
The first is a PDF of the incident write-up for a compromise that occurred in July 2006. The second is a follow-up, and both are very interesting.
I'm going to take a process-oriented view of things. Please don't ask me if someone who defaces web pages and knows some PHP code qualifies as a "cyber-terrorist". I don't want to get mixed up in semantics.
This whole thing seems to have started on or about 11 July 2006 with a web page defacement. Evidently, the bad guys gained access to a vulnerable system (found via Google) and installed a PHP 'shell'. Page 8 of the write-up specifies the need for a "real-time forensic analysis", due to the fact that not only did the good guys need to "stop the bleeding", but they had to counter the bad guys, who were not only deploying their own counter-measures, but attacking the good guys, as well. What's interesting about this is that on page 8, the authors mention having to battle active attacks from the bad guys, saying it was a "fight between the attackers...and the incident response personnel." Oddly, pages 9 - 11 included the 12 steps that the IR personnel went through, yet nothing was mentioned about having to battle an attack. The document continues into "Attack Methodology" and "Conclusions" with no mention of IR personnel being hammered by attacks from the bad guys.
Another interesting point is that the authors mention that the user-agent found in some web logs included the term "SIMBAR", and concluded (with no supporting info) that this meant that the attacker's system was infected with spyware. While I'm not discounting this, I do find it odd that no supporting information was provided. I did a search and found references to adware, but I also found a reference to the SIMS game, as well.
Continuing along into the follow-up report, "SIMBAR" is mentioned again, and this time the authors seem to believe that this user-agent indicates that the same computer was used in multiple attacks. IMHO, this is perhaps dubious at best, particularly if it is indicative of adware...adware can be fairly widespread. Also, beyond that, I'm not sure how significant this information really is to the overall incident.
Overall, both write-ups seem to indicate that the attackers used known exploits to gain access to systems, and used relatively known and easily available tools to gain their foothold. It also seems that the authors made several unsupported assumptions. At first the write-ups are interesting read, but when you really try to dig into them and get some meat, IMHO, it just isn't there.
But hey, who am I? What do you think?
Addendum 18 Nov: Besides the comments here, there's been corresponding posts over on TaoSecurity. I just want to say that I'm not trying to grill the authors of the documents, nor am I trying to point out every little detail that I think was mishandled...not at all. What I am saying is that I think the authors did a great job, but there are things that could have been handled a bit better. Richard Bejtlich mentions "focus and rigor" in one of his recent posts...just because something is done by volunteers, does that mean that quality should suffer?
Subscribe to:
Posts (Atom)