Yesterday the IPKat reminded readers that this blog does not refuse to post comments with which he and Merpel disagree. Since then it has received a number of comments to contrary effect. One, for instance, reads:

"I have posted much comments in latest days such as information from enlarge appeal board and trying to get letter to administrating council. No comment is ever put in the blog. No one comment. Is strange I think because much comments are more critic".

This Kat repeats: we are perfectly willing to post comments that are relevant to the post on which they are commenting, regardless of the position they take, and so long as they are not abusive or obscene.  He does not think it strange when only one side is represented in readers' comments since it's quite a frequent occurrence -- but he agrees that, the larger the number of comments received on any given blogpost, the more unlikely it is that readers will be reflecting the same view.

Incidentally, the IPKat and Merpel don't actually reach a consensus position and then press for it: the team consists of some ten IP enthusiasts from different countries and with different backgrounds. Sometimes some members of the blog team consult with one another or see each other's posts before they go live, but this is not the rule.

Another anonymous commenter wrote as follows:

"I have commented many times on this blog. Most comments are posted, but I find comments that tend to be critical, directly or indirectly, of the original poster (not o the patently-o type) tend to go amiss. I know that sometimes my postings do not appear because I failed to prove I was not a robot and closed the box without realizing, others I guess may have seen lost somewhere else along the way, but since the ipkat censorship assertion several months ago, I am finding more posts going missing as described.

If posts do go amiss for technical reasons are the ipkat administrators aware of this problem, and how are we to judge whether the censorship line has been crossed?"

For obvious reasons the IPKat's authors (we all check for comments to moderate) cannot be aware of a problem of posts that go missing unless someone tells them, If you have tried to post a comment and it has not appeared on the blog, please email the IPKat at theipkat@gmail.com (using an anonymous or pseudonymous email source if you like) and let us have sight of the text in question. We will either post it or, in the unlikely event that it does not meet our criteria, we will respond and explain why.  This Kat will also raise the question with his fellow Kats as to whether we might ask a suitably non-bloggy person to act as an independent referee in the case of comments that are received but not posted.

The following links may also be of some assistance:

• Diagnosing problems with Blogger comments here
• Troubleshooting comments for Blogger here

FURTHER NOTE: since posting this item, it occurs to this blogger that comments are sometimes received as emails to individual members of the blog team, and sometimes to an unattended Gmail account that is used solely for the purposes of being able to log on to Blogger and compose blog posts. Also, some people try to respond to blog posts which they have received by email, clicking "reply" and responding to the Google Group which sends out the emails in the first place.  PLEASE: if you want to post a comment, can you seek to do so initially via the "Comment" link at the foot of the blog post upon which you seek to make a comment. 

Exploit Artifacts
There was an interesting blog post on the MMPC site recently, regarding an increase in attacks against the Help and Support Center vulnerability. While the post talks about an increase in attacks through the use of signatures, one thing I'm not seeing is any discussion of the artifacts of the exploit. I'm not talking about a secondary or tertiary download...those can change, and I don't want people to think, "hey, if you're infected with this malware, you were hit with the hcp:// exploit...". Look at it from a compartmentalized perspective...exploit A succeeds and leads to malware B being downloaded onto the system. If malware B can be anything...how do we go about determining the Initial Infection Vector? After all, isn't that what customers ask us? Okay, raise your hand if your typical answer is something like, "...we were unable to determine that...".

I spoke briefly to Troy Larson at the recent SANS Forensic Summit about this, and he expressed some interest in developing some kind of...something...to address this issue. I tend to think that there's a great benefit to this sort of thing, and that a number of folks would benefit from this, including LE.

Awards
The Forensic 4Cast Awards were...uh...awarded during the recent SANS Forensic Summit, and it appears that WFA 2/e received the award for "Best Forensics Book". Thanks to everyone who voted for the book...I greatly appreciate it!

Summit Follow-up
Chris and Richard posted their thoughts on the recent SANS Forensic Summit. In his blog post, Richard said:

I heard Harlan Carvey say something like "we need to provide fewer Lego pieces and more buildings." Correct me if I misheard Harlan. I think his point was this: there is a tendency for speakers, especially technical thought and practice leaders like Harlan, to present material and expect the audience to take the next few logical steps to apply the lessons in practice. It's like "I found this in the registry! Q.E.D." I think as more people become involved in forensics and IR, we forever depart the realm of experts and enter more of a mass-market environment where more hand-holding is required?

Yes, Richard, you heard right...but please indulge me while I explain my thinking here...

In the space of a little more than a month, I attended four events...the TSK/Open Source conference, the FIRST conference, a seminar that I presented, and the SANS Summit. In each of these cases, while someone was speaking (myself included) I noticed a lot of blank stares. In fact, at the Summit, Carole Newell stated at one point during Troy Larson's presentation that she had no idea what he was talking about. I think that we all need to get a bit better at sharing information and making it easier for the right folks to get (understand) what's going on.

First, I don't think for an instant that, from a business perspective, the field of incident responders and analysts is saturated. There will always be more victims (i.e., folks needing help) than there are folks or organizations qualified and able to really assist them.

Second, one of the biggest issues I've seen during my time as a responder is that regardless of how many "experts" speak at conferences or directly to organizations, those organizations that do get hit/compromised are woefully unprepared. Hey, in addition to having smoke alarms, I keep fire extinguishers in specific areas of my house because I see the need to immediate, emergency response. I'm not going to wait for the fire department to arrive, because even with their immediate response, I can do something to contain the damage and losses. My point is that if we can get the folks who are on-site on-board, maybe we'll have fewer intrusions and data breaches that are (a) third-party notification weeks after the fact, and (b) actually have some preserved data available when we (responders) show up.

If we, as "experts", were to do a better job of bringing this stuff home and making it understandable, achievable and useful to others, maybe we'd see the needle move just a little bit in the good guy's favor when it comes to investigating intrusions and targeted malware. I think we'd get better responsiveness from the folks already on-site (the real _first_ responders) and ultimately be able to do a better job of addressing incidents and breaches overall.

Tools
As part of a recent forensic challenge, Wesley McGrew created pcapline.py to help answer the questions of the challenge. Rather than focusing on the tool itself, what I found interesting was that Wesley was faced with a problem/challenge, and chose to create something to help him solve it. And then provide it to others. This is a great example of the I have a problem and created something to solve it...and others might see the same problem as well approach to analysis.

Speaking of tools, Jesse is looking to update md5deep, and has posted some comments about the new design of the tool. More than anything else, I got a lot out of just reading the post and thinking about what he was saying. Admittedly, I haven't had to do much hashing in a while, but when I was doing PCI forensic assessments, this was a requirement. I remember looking at the list and thinking to myself that there had to be a better way to do this stuff...we'd get lists of file names, and lists of hashes...many times, separate lists. "Here, search for this hash..."...but nothing else. No file name, path or size, and no context whatsoever. Why does this matter? Well, there were also time constraints on how long you had before you had to get your report in, so anything that would intelligently speed up the "analysis" without sacrificing accuracy would be helpful.

I also think that Jesse is one of the few real innovators in the community, and has some pretty strong arguments (whether he's aware of it or not) for moving to the new format he mentioned as the default output for md5deep. It's much faster to check the size of the file first...like he says, if the file size is different, you're gonna get a different hash. As disk sizes increase, and our databases of hashes increase, we're going to have to find smart ways to conduct our searches and analysis, and I think that Jesse's got a couple listed right there in his post.

New Attack?
Many times when I've been working an engagement, the customer wants to know if they were specifically targeted...did the intruder specifically target them based on data and/or resources, or was the malware specifically designed for their infrastructure? When you think about it, these are valid concerns. Brian Krebs posted recently on an issue where that's already been determined to be the case...evidently, there's an issue with how Explorer on Windows 7 processes shortcut files, and the malware in question apparently targets specific SCADA systems.

At this point, I don't which is more concerning...that someone knows enough about Seimens systems to write malware for them, or that they know that SCADA systems are now running Windows 7...or both?

When I read about this issue, my first thoughts went back to the Exploit Artifacts section above...what does this "look like" to a forensic examiner?

Hidden Files
Not new at all, but here's a good post from the AggressiveVirusDefense blog that provides a number of techniques that you can use to look for "hidden" files. Sometimes "hidden" really isn't...it's just a matter of perception.

DLL Search Order as a Persistence Mechanism
During the SANS Forensic Summit, Nick Harbour mentioned the use of MS's DLL Search Order as a persistence mechanism. Now he's got a very good post up on the M-unition blog...I won't bother trying to summarize it, as it won't do the post justice. Just check it out. It's an excellent read.

I know, interesting post title, right...just couldn't come up with anything witty...sorry.

Well, Rob Lee ran us (me, Chris Pogue, and David Hull) through the SANS Essential Incident Response WebCast yesterday, and two out of three panelists agree that Cory Altheide is THE indispensable incident response tool! The mini-panel was a lot of fun and I hope folks listening to it take it as a harbinger of things to come this summer at the Summit.

Speaking of conferences, I ran across SecureArtisan's comments (day 1, day 2, day 3) from attending the CEIC Conference. It appears that there were some interesting presentations, some of which may have been interesting in title only. Reading through his comments, I have to agree with some of them from my own experiences, as this is why I've stopped trying to attend some conferences. What have you seen?

Also, I wanted to share some comments (posted with the author's permission) I've received lately from folks regarding tools...the first is from Brian Perkins, who said:

I just wanted to drop you a quick note regarding a recent success story using your FRUC client and the FSP Server. One of the data points I collect is autorunsc.exe –a. With this collection of data I was able to identify the malicious software in a matter of minutes even before acquiring an image. I have made great use of your FRUC client and server to the point that it serves as my first tool to deploy for Incident Response, and it now sits at the core of my Forensic Investigation Protocol . Getting the volatile data first and then the static data (hdd image) second is my order of priority. Using your tools has made my time well spent when as we all know how efficient a tools performs depends upon its success. Now I going to let Reg Ripper have a go at the hives!

If you remember, the FSP is one of the tools available on the DVD that accompanies the first edition of Windows Forensic Analysis (and yes, it is on the DVD with the second edition, as well).

The second comment is from Ian Hutchison, and has to do with the rp.pl Perl script that I mentioned in a previous post; Ian asked for a copy and ran it after I sent it, and this is what he had to say:

I ran this and it chewed threw 114 restore points in less than a second. That would have taken me hours if not days to do manually, and seriously messed with my sanity.

I want to thank both Brian and Ian for their comments, and for allowing me to post them. While it's nice to see comments like this out in public view, more than anything else, these comments show that there are folks out there looking for answers in other areas of a system or an image aside from just the file system, and moving beyond the traditional, purist approach to computer forensic analysis.