Forensic string searching

Can the principle of "least frequent occurrence" be applied to digital forensic string searches?

Late last night (or painfully early this morning) I published a new post over at the SANS Digital Forensics Blog. The post is called "Least frequently occurring strings?" and attempts to shed some light on that question.

I've used this approach on a couple of recent cases, one real and one from The Honeynet Project's forensic challenge image found here, this is the image the post contains data from.

I really knew nothing about the Honeynet challenge case, but in less than half an hour, I'd located an IRC bot using the LFO approach to analyzing strings. Of course the Honeynet case is quite small, so the technique worked well, on larger cases from the real world, I expect it's going to take longer or maybe not work at all. Nevertheless, LFO is a concept that other practitioners have been applying for some time now.

There's lots of other goodies in the post, like moving beyond just using strings to extract ASCII and Unicode text from disk images. If you have a decent system and a good dictionary file, you can reduce this set of data even further to lines that actually contain English words.

Check it out, I hope the world finds it useful.

Incident Response Triage

Your phone rings, it's the Help Desk. They are calling you because they've got a few dozen systems that have been hit with malware that apparently came into the organization via phishing. Unfortunately, your team isn't large enough to respond to all of these systems simultaneously. You've got to quickly prioritize.

You call the members of your team together and start delegating tasks. One person contacts the email admins and finds out who received the phishing email and compares that list against the one the Help Desk gave you. The email admins remove the offending message from user mailboxes and blacklist the sender. You ask them to send a copy of the message to you so you can dissect it and begin the process of analyzing the malware.

You learn of another dozen potentially compromised hosts from conversations with the email admins.. You add them to your list. How do you prioritize your response to these victim systems? Let's say your company is very large, Fortune 100, and has been through a series of mergers and acquisitions over the last several years, nearly all of the names on the list of affected users are unknown to you. On the one hand, this may be good as it's likely none of these individuals are C-level execs. On the other hand, you've now got to figure out who these people are and what data they have on their systems and what data they have access to and who their local IT support personnel are.

What are your next steps? Do you contact each user and survey them, asking what kind of data they deal with and have access to? Do you ask who their IT support person is? How accurate is the information you're going to get? What if some of these systems are multi-user and the user you're talking to is unaware of the special projects and associated data?

Aside from questioning users, what other information gathering do you need to do? Does your organization have good exfiltration monitoring and logging in place? Do you have the ability to pull those logs and see what, if any, data has left the org? Do you have the ability to rapidly block outbound connections to the malware's command and control networks?

I know I'm asking more questions than I'm answering, partly this is stream-of-consciousness writing, but I'm also soliciting input on IR triage for a project I'm working on. I've started a little IR triage tool I'm calling Windows Automated Incident Triage or WAIT. Here is the current capability roadmap for WAIT: identify users on a system and their privilege levels, catalog the data those users have recently accessed on their systems, create a list of file shares those users have recently accessed, gather available web history, collect information about the system's OS revision and a list of installed software.

My hope is that this information will be useful to IR professionals in a situation like that above. I want a tool that can be used to help prioritize IR. What artifacts am I missing that may also be useful?

And of course the tool will be open source, likely released under a BSD style license.

How to find base64 encoded evidence

Today I released a post over at the SANS Digital Forensics Blog discussing how to find evidence that may have been base64 encoded and therefore not found by traditional tools that categorize files based on magic numbers.

The technique is really simple, but I hadn't seen it discussed elsewhere, perhaps because it's so obvious.

Enjoy.

Update: Here's a text file containing some magic byte sequences for common image types that have been base64 encoded: http://trustedsignal.com/forensics/b64_enc_img_types.txt.

Trust those time stamps?

I've got a new blog post up at the SANS Digital Forensics Blog titled Digital Forensics: Detecting time stamp manipulation. The post is my effort to demonstrate that time stamp manipulation on systems running NTFS can be spotted (for now) if examiners take the time to fully investigate all of the available evidence (i.e. compare $STANDARD_INFO and $FILE_NAME) time stamps.

This is another barrage in my quest to get Brian Carrier, a true giant in this field, to add the capability to fls to pull $FILE_NAME time stamps into the body file format so we can build time lines using mactime that include both $STANDARD_INFO time stamps and $FILE_NAME time stamps.

Fortunately, Mark McKinnon has written a tool called mft_parser that will do this. As soon as that tool is available for wider release, I'll post a link.

Oh and I said for now, because I'm confident that the right rootkit will be able to manipulate $FILE_NAME time stamps as well as $STANDARD_INFO time stamps. In such cases, we'll have to rely on time stamps in other artifacts.

Windows Persistence

I wrote up a post on the SANS Digital Forensics blog titled Digital Forensics: Persistence Registry keys where I gave a couple of links to text files containing Registry keys for Windows XP SP3 system that I'd run Autoruns on to gather a list of Registry keys that could (possibly) be used as persistence vector's for malware.

I have collected similar lists for Windows Vista and Windows 7. The files are available at trustedsignal.com/IR.

I see what you did there

I had the pleasure of presenting at Security BSides in KC this morning. Shouts out to hevnsnt and bsideskc for putting on the event.

Unfortunately, my schedule didn't allow me to see all of the talks, but what I did see was valuable, though the "face time" with my peers in the field (I met hal_pomeranz and kriggins in the flesh) was probably more fun than presenting or watching any of the presentations I was able to see.

My talk was called I see what you did there, and was about time lines in forensic investigations and incident response. Some of the material in the talk comes out of SANS 508: Computer Forensic Investigations and Incident Response, a course I've had the pleasure of teaching a few times. Thank you to Rob Lee and his contributions to the field over at the SANS Digital Forensics Blog. Obviously, the six day course is able to cover this topic in much more detail than I was able to do in one hour.

BSides is awesome. Everyone should submit talks, it makes you better, even if you can't talk about an original tool or concept, many people don't know what you know and when you prepare to share it with them, you become more knowledgeable than you were when you started.

Givem 'em enough rope

I mentioned on Twitter that having worked in relatively unrestricted environments (higher ed) and in highly restricted environments (banking) and in between, that in my experience, those environments with more draconian policies have better security.

No sooner than I hit "Send", I realized I should have also said "controls" because policies by themselves are pretty lousy security controls.

Since Twitter is less than ideal for elaborating on, well, much of anything, let me explain what I mean, for those who may not agree.

Most of my work in information security has been in the incident response and forensics space, with a few years in application security -- I'm a recovering developer.

During my time in higher ed, most users ran as admin and could install whatever they wanted, whenever they wanted. They could browse to any web site of their choosing. This is the "give 'em enough rope" approach to information security. The problem is that this doesn't just lead to the users hanging themselves. Shops operating in this manner are giving their employees enough rope to hang the entire organization.

During my tenure in the financial sector, few people ran as admin, application whitelisting was in effect for most people and web content filtering kept most people from browsing to known-malicious or "inappropriate" domains.

The results of these two disparate approaches was striking. Higher ed was an incident responder/forensic investigator's dream job as there was never a shortage of interesting work. By contrast, the bank didn't have any full time incident response and forensics folks. During my two years at the bank, we had less than a handful of issues and they were all drive-by-downloads from rogue advertisements on mainstream web sites.

I believe most organizations could greatly improve their security and reduce costs by taking away internet access for those employees that don't need it and greatly restricting internet access for those who do need it. It's unpopular, it's draconian, but it works.

Don't let your users run as admin. I can't believe we're still seeing this as much as we are. If you have some users who need admin access, give them separate accounts to use when they need that level of access.

Whitelisting. It sucks. It's a horrible pain for the users and those who have to maintain it. Before I worked in an environment that used it, I dismissed it completely. But as much as it sucks and is painful to implement and maintain, it will reduce the number of security incidents that you have to deal with. Note, if you take away your user's admin rights, you may not need whitelisting.

I've said almost nothing of application security, but this is another area where more restriction leads to greater security. Limit your developers access to production environments, don't let them adapt new technologies/frameworks/libraries without first taking the time to review the security of those technologies. Don't let devs move forward on projects until threat models have been developed and threats have been addressed. Don't let code go to production without some type of review, don't push applications to prod without security testing those apps, etc.

Yes, this is expensive and time consuming, but in my opinion it's a pay now or pay more later scenario. Spending thousands up front may save you from spending hundreds of thousands after a breach.

Will all of this save every organisation 100% of the time? No, but it will significantly reduce the number of incidents. Will it be popular with employees? No, but watching Double Rainbow Song is probably something they should do on their own time and on their own computer.

Security will never be perfect, but a big part of the reason it is as broken today as it is, is because we haven't made the unpopular decisions that need to be made.